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December-január fordulóján hirtelen annyi munkánk lett, hogy egyre nagyobb 
erőfeszítésembe került az általunk indított levelezési listák forgalmának 
nyomon követése. Bárhogy küzdöttem, az olvasatlan levelek száma egyre csak 
szaporodott, mígnem feladtam a küzdelmet: beszüntettem szeretett listáim ol- 
vasását. Most visszanéztem rá: összesen mintegy hatezer olvasatlan levelem 
keletkezett. Szép szám! De mit kezdjek ezzel a levéltömeggel? 

A levlista olyan kicsiben, mint az Internet nagyban: az ömlesztett , informá- 
ció"- jelentős százaléka zaj, a maradék pedig koherenciamentes infopép. Aki 
ebből tanulni akar, igen erős alapokkal kell, hogy rendelkezzen. Egy megfe- 
lelően felkészült szakember ugyanakkor katasztrofális jel/zaj-arányt érzékel, 
és mint megszűrhetetlent, kihajítja az egészet. Tudják, mi a reménytelen? 
Aranyat mosni a fürdőkád vizében. 

Most, hogy ismét elkezdtem levlistázni (de most már nem a válaszadás belső kényszerével, hanem külső 
szemlélőként, olvasgatva követem), úgy látom, egyesek pontszerű kérdéseire mások pontszerű válaszokat 
adnak. Mintha egy pointillista festményen odaböknénk egy pontra, és megkérdeznénk: ez milyen színű? 
Sárga. És amott? Ott kék. De miért? Ha távolabbról nézzük, akkor áll össze a teljes kép, és az emberen úr- 
rá lesz az , Aha!"-érzés. Többé már nem is kell rákérdeznie az egyedi pontocskák színére. Vagy talán még 
jobb példa a kotta. Kodály országában mindenki tanul zenét, tán még a violinkulcs szerepe is világos - de 
hiába nézzük a kottabogyókat (c, e, c, e, g, g), nem szólal meg bennünk a zene. 

Remélem, a tech.net magazin rendszeresen nyújt , Aha" élményt. Ha nem, az sem baj: mindenkinek ta- 
nulnia kell a teljes egész felismerését. Van, akinek elég a kotta, és megszólal fejében a szimfónia. Több- 
ségünk nem ilyen. Ismerhetjük ugyan a kottajeleket, de a koncert nyújtja az igazi élményt. 

Ebben a hasonlatban a tech.net magazin a kotta, s a MesterOrzus előadás a koncert. Ősztől újraindítjuk 
korábban megismert MesterOrzus előadásainkat. A jól bevált célokon és felépítésen nem változtatunk: 
havonta egy délután szeretettel várjuk olvasóinkat a tech.net magazinhoz kapcsolódó előadásokon. Változik 
viszont az időpont, valamint a helyszín - de ezeket a lényegtelen apróságokat a hamarosan postázandó 
belépőjegyeken is feltüntetjük. Sokkal fontosabb az a változás, hogy - mivel az évek során meglehetősen 
nagy mennyiségű előadásanyagot halmoztunk fel - rendelkezünk vázlatos előadástervvel, így ki-ki idejeko- 
rán eldöntheti, melyik előadás érdekli. Íme a majdnem véglegesnek mondható őszi kínálat: 


Golyóálló webkiszolgáló Windows Scripting Host Active Directory Services Interface 
Újdonságok a .NET Serverben Group Policy Remote Installation Services 
.NET Framework bevezető Objektumorientált alapelvek --DP Cct 
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Resszkessenek a hackerek? 


bűncselekmény elkövetőjévé válik, és két évig terjedő szabadságvesztéssel számolhat. 
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Több alkalommal is felmerült a NetAcademia listáin a kérdés, vajon hogyan lehetne megállapítani, 
hogy egy felhasználónak milyen tényleges jogai vannak egy könyvtárban, illetve milyen eszközzel le- 


2002 Május 


Metadirectory 


A legutóbbi Tech.net magazinban áttekintettük, hogy általában milyen elvárásaink lehet- 
nek egy metacímtár szolgáltatástól. Most konkrétan a Microsoft Metadirectory Service 
(MMS 2.2) működésével ismerkedhetünk meg. 


13. oldal 


Egy eluster Administrator - (ELUSTER-O1 (.)] 


ÉG) Fe View Window Help ] 










0 CORP-MSG-O1 IP Addr 
Ü1CORP-MSG-O1 Networl 
D1coRP-MSG-01 System 
ÚN0isk F: Storage Group: 
Disk 6: Log Files 

d Exchange HTTP Virtual 
"Exchange IMAPS Virtus 
DJ Exchange Information 
Ü Exchange MS Search 1 
ÚJ Exchange Message Tri 
ta Exchange POP3 Virtual 
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(VII. rész) — Cluster a gyakorlatban 

Az infrastruktúra területén tett kirándulásunk után visszatérünk 
az erőforrások világába, és megnézzünk, hogyan lehet fontos 
alkalmazásszoftvereknek magas rendelkezésre állást biztosítani. 


5. oldal 
Windows .NET 


Server Beta 3 
Folytatjuk az előzetes szemezgetést a Windows.NET Server új funkcióiból, egyelőre még mindig a béta3 
verziót használva - no és persze ismét teszünk egy kis kitérőt a belső fejlesztési folyamatok rejtelmei felé... 


9. oldal 


63-CI Custer Configuration 
E- érj CORP-SRV-OL 
E- díj CORP-SRV-OZ 











Az a szakértő, aki tudásával, ismereteivel segíti a hackert, ugyancsak 


18. oldal § 


Támadás az IPSec ellen 
Amire az IPSEC csomagszűrőnél figyelni kell 


A tech.net magazin III. évfolyamának első számában olvashattuk, hogyan használható a Windows 
2000 IPSec implementációja, mint egyszerű csomagszűrő. Sajnos ez a tulajdonság csak melléktermék, 
tervezéskor egyáltalán nem szerepelt a célok között. Ezt hallva az olvasó rögtön gyanút foghat, vajon 
nem származik-e ebből valami alapvető probléma. 
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(  Azatábbitata azokat az emordélyeket mata, smelyekat a kiöt csepot vagy el 
)  száimazható engnáby alactán magan, 


eeztsgyijozeltate 


Hatbíron engedétrek 


DumpSec 
NTEFS jogosultság listázása 


( E Fügöklörébezésa. séatok iráza 
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hetne akár egy egész könyvtárstruktúra aktuális hozzáférési szabályairól kimutatást készíteni. Nos, egy 
beépített eszköz és egy szabadon használható szoftver megoldást jelenthet a problémával küzdőknek. 
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143 sávos aszfaltozási munkálata 


Egy memóriában tárolt adatbázis óriási kincs, de csak akkor, ha stabil technológiai kapoccsal 
összeköthető a meglévő adatbázisszerverekkel és a helyi gépeken tárolt XML állományokkal. 





00 p.s 7. 
XMLgessünk Ér A) 
ema (II. rész) Úi Bbé 
Az előző részben láthattuk, hogyan kell közvetlen egymásba ágyazással, referen- 
ciákkal és típusok definiálásával egyszerűbb sémákat szerkeszteni. Részletesen 
megnéztük hogyan lehet egyszerű típusokat létrehozni a már meglévő típusokból. 
Ebben a részben a komplex típusokat tekintjük át. Megnézzük, hogy összetettebb tí- 
pusok létrehozására milyen fejlettebb nyelvi elemek állnak rendelkezésre. 








SelectCommand tulajdonságadatát kell feltölteni az 
visszanyerését szolgáló SalCommand objektummal. 









Dim conSzamla As New SalConnection( 
W"user idssazpasswordshalihoz"t 8 
"databasesSzamla:data sourcezGepl") 
Din cudPartner As New SalComnand( 
W"Select " From Partner Where PaTipus-. 
WconSzanla) 
Din daPartner As New SalDataAdapter 


Adathíd 































Az alábbi cikk a két kapcsolódási felület közül az elsőt elemzi, és az SOLServer adatbázis és a Dim dsPartSzla As New DataSet sg; 
DataSet objektum közötti híd ,aszfaltozási munkálataiba" avatja be az Olvasót. kezóztundéseszektsszzezttazkabazai fú 
AP I od a Ezzel tehát a híd az SOLServer adatbázisból a DataSet i Kg 
at már járható, így átjuttathatók rajta az adatok a Fill() ru 
d Ej 
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ez boe ei zzti Exchange 2000 
Terminal Services Ptofile Exchange Genetal sé e . . . 
Egyes Et srreettl Felhasználók, csoportok, címlisták 
ener Address [ Áccount [/ Profile elephones [01 
ET Az előző szám végén ott tartottunk, hogy a felhasználók beállításai jönnek. 
e Jakab Gipsz Jöjjenek, és nemcsak a felhasználók, hanem az e-mail címmel rendelkező egyéb 
2 EE z objektumok - tehát a kapcsolatok (Contacts) és az e-mail címmel rendelkező 
csoportok - tulajdonságait is megnézegetjük ebben a részben. 
Exchange 2000 :-. 5—zt [TE 
4 e ta 
nang 6 [ [A ! 
Server és web storage system Válasz vs 
Felhasználó Munkaállomás : NET Framework 


Korábban bemutattuk, hogyan lehet az Exchange2000 Server Web Storage System-ét 


(WSS) elérni ADO-n (ActiveX Database Objects) keresztül. Most a .NET keretrendszer 
segítségével állunk neki a feladatnak. Egyelőre azonban - sajnálatos módon előre 
láthatatlan ideig - ADO.NET-ben nincs támogatás az Exchange2000 Server és a WSS 
elérésére. Ezért más, .NET alatt is használható megoldások után kell néznünk. 
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E3-CI Windows Settings 
63-CI Administrative Templates 


Úgy tíz évvel ezelőtt egy Deltában láttam, amint japán kutatók bemutatták, hogyan tudnak 
szemétből gyémántot előállítani, mondhatnám varázsolni. Önkéntelenül ez jutott eszembe, 
amikor először hallottam a Farsite-ról, mert ezzel temérdek 
ócskavasból (azaz idejétmúlt, de még nem teljesen használhatatlan számítógépből) 

gigászi tárhelyet, amolyan internetes bőségszarut építhetünk. 
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(VII. rész) — Cluster a gyakorlatban 


Az infrastruktúra területén tett kirándulásunk után visszatérünk az erőforrások 
világába, és megnézzünk, hogyan lehet fontos 
alkalmazásszoftvereknek magas rendelkezésre állást biztosítani. 


Látni kell, hogy itt már nem pusztán egy szolgáltatást hozunk lét- 
re, hanem egy teljes alkalmazást helyezünk el fürtözött környe- 
zetben, ez pedig minden eddiginél nagyobb figyelmet követel tő- 
lünk. A következőkben két Microsoft-terméket és egy harmadik, 
más gyártótól származó szoftvert vizsgálunk meg. 


A Microsoft Exchange fürtkörnyezetben 

Az Exchange Server az 5.5-ös verzió óta támogatja a clustertechno- 
lógiát, mi azonban most csak a Windows 2000 - Exchange 2000 pá- 
rost vizsgáljuk. Ebből sem valamennyi verziót: csak az Exchange 
2000 Enterprise Edition változat képes együttműködni a fürtszolgál- 
tatással, vagyis ezen változat megléte követelmény a telepítéshez. 
A Microsoft üzenetkezelő-alkalmazása natív módon támogatja a 
fürtkörnyezetet. Ez azt jelenti, hogy saját erőforrás DLL-ekkel ren- 
delkezik, amelyek az Exchange-komponensek és a fürt közötti 
kommunikációt biztosítják. Pontosan ismeri azokat a fogalmakat, 
amelyekre a Microsoft fürtrendszer épül -a csoport, az erőforrás, 
a függőség és a guorum fogalmát. Többféle konfigurációt is lét- 
rehozhatunk (aktív-aktív, aktív-passzív), sőt datacenter környe- 
zetben négy állomáson akár 3 aktív-1 passzív felállást is építhe- 
tünk. A négy aktív állomás egyelőre nem támogatott. 

Az alkalmazás tervezőmérnökei az , Exchange Virtual Server" fo- 
galmát úgy valósították meg, hogy az egybeesik a fürt , csoport"- 
objektumával, ha a következő feltételek teljesülnek: a csoportnak 
van fizikai lemez, IP-cím és hálózati név erőforrása, továbbá a 
teljes fürtre vonatkozóan már létezik a , System Attendant" nevű, 
az Exchange 2000 részeként szállított erőforrás. 

Az Exchange egyes komponensei pontos függőségi viszonyban 
vannak egymással, ahogy ezt az alábbi ábra mutatja: 


SMTP KA IMAP4 KE [SIC iden 










Message 
Transfer teme 
Agent 


a Az Exchange-komponensek függőségi rendszere 
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A levelezőt jól ismerő Olvasónak feltűnhet, hogy korántsem teljes 
ez a lista. Valóban. Sajnos az Exchange 2000 bizonyos komponen- 
sei nem fürtözhetők. Íme a lista: 

0 Microsoft Active Directory" Connector (ADC) 

Chat Service 

Microsoft Exchange 2000 Conferencing Server 

Instant Messaging 

Key Management Service 

Exchange Calendar Connector 

Exchange Connector for Lotus cc:Mail 

Exchange Connector for Lotus Notes 

Exchange Connector for Microsoft Mail 

"0 Exchange Connector for Novell GroupWise 

"2 Event Service 

"2 Network News Transfer Protocol (NNTP) 

"0 Site Replication Service (SRS) 

Eltérően a korábbi verziótól, akkor sincs mód a komponenst ön- 
állóan az állomásra telepíteni, ha maga esetleg önálló alkalmazás 
lenne (csevegés, azonnali üzenetküldés, konferenciaszerver) , mert 
a protokollinformációk a fürtben találhatók. Ha tehát szükség van 
ezekre az alkalmazásokra, akkor újabb, önálló Exchange Servert 
kell telepítenünk. Azért nem olyan vészes a helyzet: az ADC és az 
SRS csak átmenetileg szükséges (amíg 5.5-ös rendszerünkkel kell 
együttélnünk), a konnektorok pedig nem fürtözött szolgáltatás- 
hoz kapcsolódnak - így valószínűleg nem keletkezik Achilles sa- 
rok attól, hogy a csatolószoftver nem fürtözhető. 

Nem korlát, de jó, ha tudjuk: az MTA erőforrás mindig aktív-pasz- 
szív, másképp fogalmazva, egy fürtben egyszerre csak egy MTA 
erőforrás lehet aktív, még datacenter esetében is. Az MTA mindig 
az első virtuális szerveren jön létre, és ha később törölnénk, új 
csoportba költözik mindaddig, amíg legalább egy Exchange vir- 
tuális kiszolgáló létezik a fürtön. 
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Az Exchange 2000 telepítés előkészületei 

Járjuk körül egy kicsit pontosabban, mit is jelent az aktív-aktív, 
illetve az aktív-passzív konfiguráció! Azt a korábbi cikkekből már 
tudjuk, hogy a Microsoft fürt-implementációja nem nyújt terhe- 
lésmegosztást, nem erre tervezték. Minden egyes létrehozott erő- 
forrás számára a rendelkezésre állás növelését kínálja. Aktív- 
passzív beállításnál ez egyértelmű. Az egyik állomás helyet ad az 
Exchange virtuális kiszolgálónak, vagyis a fürt egy csoportjának, 
ha pedig valamilyen hiba lép fel, ez a csoport átköltözik a másik 
szerverre, amely eddig csak magában dohogott. Aktív-aktív rend- 
szernél sincs ez másképp, a különbség az, hogy a második állo- 
máson is van egy virtuális Exchange kiszolgáló. Milyen funkciót 
lát el? Bármi mást, mint az első. Ha például az egyik fürtcsoport 


SUDE. ÚS: 


a felhasználók postaládáit kezeli, a másik állomáson a másik 
Exchange a nyilvános mappákat. Az aktív-aktív jelző tehát a tel- 
jes fürtre értendő, nem az egyes virtuális szerverekre, azok ugyan- 
is mindig csak az egyik node-on futnak. 

A tervezésnek más fontos momentuma is van. Egy Exchange 2000 
kiszolgálónak legfeljebb négy ún. adattárcsoportja (storage group) 
lehet. (Ez nem keverendő össze a fürtcsoporttal. Az adattárcsoport 
olyan, mint egy adatbázis az 5.5-ös verzióban, persze számos új tu- 
lajdonsággal.) Itt szándékosan nem virtuális kiszolgálóról beszé- 
lünk, hanem valódiról. Tehát egy fürtállomáson is legfeljebb négy 
adattárcsoport lehet. Ebből viszont következik, hogy a teljes fürt- 
ben nem érdemes négynél több adattárat definiálni. Ha az alábbi 
ábrán a második virtuális kiszolgálónak át kellene költöznie az el- 
ső állomásra, a három adattárcsoportjából csak kettő indulna el: 


Exchange 
Virtuális szerver 1 


Exchange 
Virtuális szerver 2 
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5 Az adattárak száma nem lehet több négynél egy Advanced 
Server fürtben 


A telepítésnek vannak olyan feltételei, amelyek nemcsak a fürtök- 
re, hanem minden Exchange kiszolgálóra érvényesek, (pl.: DNS, 
AD, GC telephelyek stb.). Ez azonban nem témája vizsgálódásunk- 
nak. Vannak viszont a fürttel kapcsolatos egyedi feltételek is, 
amelyeket be kell tartani. Ezek: 

"2 Egyszerre nem szabad telepítést végezni mindkét állomáson. 
Az idővel nem így kell takarékoskodni. Különösen igaz ez, ha 
tartományvezérlőkre telepítjük a rendszerünket. 

A fürtszolgáltatás fiókja legyen tagja az , Exchange Full 
Administrators" csoportnak! Figyelem! Ezt mindkét állomáson 
érvényre is kell juttatni, vagyis a fürtszolgáltatást legalább 
egyszer újra kell indítani, vagy meg kell várni, amíg a 
Kerberos jegyet megújítja a szolgáltatás (8 órán belül). 

A telepítést a két állomáson szimmetrikusan kell elvégezni -— 
ugyanazokat a meghajtókat kell használni. Az alkalmazást 
nem kell közös lemezre tenni, használható a ,C:YProgram 
filesYExchgsrv" mappa. 

Kötelező felrakni legalább a , Messaging and Collaboration" és a 
Microsoft Exchange System Management Tools" komponenseket. 
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A továbbiakban feltételezem, hogy az erdő- és tar- 
tományelőkészítés már megtörtént. A fürtre telepítés 
a következő lépésekből áll: 

1. Az első állomáson az Exchange 2000-et telepítsük 
az operációs rendszert tartalmazó lemezre! Ide kerülhet- 
nek az adatbázisok is. 

2. Végezzük el a telepítést az elsővel azonos módon a második 
állomáson is! 

3. Hozzunk létre egy csoportot a Cluster Administrator segítsé- 
gével! Adjuk meg azokat az állomásokat, amelyekre a csoport 
átköltözhet! A csoport neve legyen a majdani Exchange 2000 
virtuális szerver neve. 

4. Hozzunk létre IP-címet, hálózati nevet és lemezerőforrásokat! 
A hálózati név lesz az Exchange 2000 szerverünk neve. 

5. A fenti csoportban hozzunk létre az erőforrás-varázsló segít- 
ségével egy Exchange System Attendant erőforrást! Tegyük 
függővé a hálózati névtől és a fizikai lemeztől! 

6. Ellenőrizzük le, hogy a , Data Directory" párbeszédpanelen a 
fizikai lemez erőforrást adtuk-e meg! 

7. Indítsuk el a , System Attendant" erőforrást! 

Ha mindent jól végeztünk, akkor a , System Attendant" elkezd dol- 

gozni, és az erőforráscsoportot további erőforrásokkal népesíti be. 


Sá cluster Administrator - (ELUSTER-01 (.)1 (-IO[] 
ETTETTÉT] 


ÉG Ele View Window Help 
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E ég) CLUSTER-O1 






50 Groups JD CORP-MSG-01 IP Address CORP-SRV-OL 
E Custer Group [JJ CORP-MSG-O1 Network Name CORP-SRV-O1 
(1 CORP-MSG-01 System Attendant CORP-SRV-O1 

CORP-MSG-OZ 


. CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
CORP-SRV-O1 
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ÚJ Disk F: storage Groups 

0 Disk G: Log Files 

ÚJ Exchange HTTP Virtual Server Insta. .. 
ÜDExchange IMAP4 Virtual Server Inst,.. 
ÚJ Exchange Information Store Instanc. ,. 


(CI Resources 
EC Custer Configuration 
- áj CORP-SRV-01 
-égj CORP-SRV-O2 


ÜDExchange MS Search Instance - (CO... 
ÜT Exchange Message Transfer Agent ... 
ÚJ Exchange POP3 virtual Server Insta... 
ÚJ Exchange Routing Service Instance ... 
ÚJ SMTP virtual Server Instance - (CO... 


For Help, press FL 


5 A System Attendant elvégezte a munkáját 


Az Exchange 2000 fürt immár munkára kész. Ha aktív-aktív rend- 
szert szeretnénk építeni, akkor a másik állomáson ugyanezeket a 
lépéseket végrehajtva új virtuális szervert hozhatunk létre. 

A telepítéskor még egy fontos dolgot kell tudni. Ha már létezik 
Exchange 5.5 rendszerünk, akkor a fürt nem lehet az első Ex- 
change 2000 szerver az adott telephelyen. A telepítés ugyan hi- 
ba nélkül lezajlik, de az Exchange konfigurációs információk má- 
solása az Exchange 5.5 kiszolgálóról nem történik meg. Ezért 
ugyanis a ,Site Replication Service" szolgáltatás a felelős — az vi- 
szont nem működik fürtön. Azt javaslom, hogy ilyen esetben elő- 
ször egy nem fürtözött Exchange 2000 kiszolgálót keltsünk élet- 
re, azon automatikusan létrejön az SRS szolgáltatás. Az Exchange 
5.5 eltűnésével a SRS szerepe megszűnik - így nem lesz akadálya 
az azonnali fürtre telepítésnek sem. 


A Microsoft SOL 2000 fürtkiszolgálókon 

Az SOL Servernél több szempontból is szerencsénk van az 
Exchange 2000-hez képest. A termék, jellegénél fogva, nem első- 
sorban szerverszolgáltatások elosztott hálózata (habár a szerverek 
közti replikáció képességével rendelkezik), sokkal inkább beszélhe- 
tünk önmagában álló kiszolgálókról, amelyek mindenekelőtt a fel- 
használókkal kommunikálnak, esetleg más — nem SOL - szolgálta- 
tások adatkezelését támogatják. Ráadásul a termék címtárszim- 
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biózisa sem olyan mértékű, mint az Exchange 2000-nél, 
inkább lehetőség, mint kötelesség. Így aztán nem kell 
csodálkozni, hogy műszaki értelemben jóval egyszerűbb 
feladat a fürtözése, mint a levelező-kiszolgálóé volt. Ha még 
azt is hozzátesszük, hogy egy SOL Server általában előbb válik 
üzletileg kritikus alkalmazássá, mint egy Exchange, akkor már szinte 
dupla a haszon. Nézzük tehát, mit kell tudni a fürtbe állításhoz. 
Az SOL fürtözési technikával való együttműködése sokat fejlő- 
dött, mára már természetes a fürt natív támogatása (saját erőfor- 
rás DLL állományokkal rendelkezik). Olyan szép ez a házasság, 
hogy nincs is szükség külön beállítgatásokra, az adatbáziskezelő 
fürtre települ, ha azt mondják neki, és a fürtből való eltávolítása 
is csak a telepítő , Eltávolítás" funkciójával valósítható meg. Akár 
16 erőforráscsoportban 16 SOL szervert futtathatunk - ennek per- 
sze nincs sok értelme, viszont az aktív-aktív rendszer jól jöhet. Itt 
az aktivitást ugyanúgy kell értelmezni, mint az Exchange 2000 
esetén. Az SOL további simulékonyságát bizonyítja, hogy az egy- 
állomásos fürttől a négyállomásos adatközpontig mindenütt ott- 
hon érzi magát a clusteren. Nemcsak a fogalmak azonosak, hanem 
a szolgáltatások igénybevétele is szabványos. Az SOL fürt ponto- 
san úgy vizsgálja önmaga egészségét, ahogy az elvárható: , looks 
alive" és ,is alive" vizsgálatokat végez rendszeresen, ez utóbbit 
SELECT DCVERSIONSOL lekérdezéssel. Egy szó mint száz, ezt a 
két alkalmazást egymásnak teremtették. 
Tiszta haszon, hogy a fürt és az adatbáziskezelő így ismerik egy- 
mást. Az SOL szerver tulajdonképpen egy erőforráscsoport lesz, 
ahogy azt vártuk. Az adatbázisok majd a közös lemezerőforráson 
helyezkednek el, és újra szükségünk lesz egy hálózati név meg 
egy IP-cím erőforrásra. No meg egy Distributed Transaction 
Coordinatorra is (a cikksorozat ötö- 
dik részében már megismerkedtünk 
vele), fürtönként egy dukál ebből. 
Ugyancsak egyetlen példány lesz 
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Oueuing (MSMO) és a ,Full Text 
Search" komponensekből. 

Talán sehol sem olyan fontos a ki- 
szolgáló méretezése, mint az adat- 
báziskezelőnél, ezért javaslom, hogy 
nagyon körültekintően becsüljük meg a felhasználók számát, a 
tranzakciók és a tárolt adatok mennyiségét, a szükséges memória 
méretét. Ebben a vonatkozásban egy fürt éppúgy viselkedik, mint 
egy hétköznapi kiszolgáló, annyi kiegészítéssel, hogy állomáson- 
ként egynél több aktív SOL kiszolgáló példány megnehezíti a dol- 
gunkat, mert a rendszer memóriáját mindkét szerver magánál sze- 
retné tudni. Egy alkalmazás egyszerű esetben Windows 2000 alatt 
legfeljebb 2 GB memóriához juthat hozzá, ami a 32 bites memó- 
riacímzésből fakad. 2"-4.294.967.296 vagyis 4 GB, ám ebből 2 
GB az operációs rendszeré. NT4 alatt ugyan megjelent a 
BOOT.INI-ben egy /3GB kapcsoló, ám ez nem oldotta meg a prob- 
lémát, csupán az operációs rendszert korlátozta 1 GB-os címtar- 
tományba, így engedve az alkalmazásoknak 3 GB-ot. 

A Windows 2000 ennél sokkal elegánsabb megoldást is hozott, ez 
pedig az AWE, azaz Address Windowing Extensions. A funkciót al- 
kalmazás-hozzáférési csatolókkal (API) lehet elérni, vagyis az al- 
kalmazásnak ismernie kell a lehetőséget és a csatolófelületet. Sze- 
rencsére az SOL 2000 ezt ismeri, így Advanced Server fürtkörnye- 
zetben hozzávetőlegesen 8 GB memóriát használhat, datacenter 
környezetben ez 64 GB is lehet. Fontos, hogy az AWE-támogatást 
be kell kapcsolni, mert az adatbáziskezelő kezdetben nem használ- 
ja. Az AWE-támogatás példányonként értendő, vagyis ha több erő- 
forráscsoportban több virtuális SOL kiszolgálót hozunk létre, akkor 
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Az átköltözési 
szabályokat befolyásolhatja az 
fürtönként a Microsoft Message eltérő memóriamennyiség vagy 
memóriaigény a különböző 

állomásokon. 
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mindegyiknél külön-külön el kell végezni a bekapcsolást. Minden- 
képpen azt tanácsolom, hogy az AWE használatát alapos teszt 
előzze meg. Az SOL többi hardverrel kapcsolatos követelményéhez 
már nem a fürt, hanem az adatbáziskezelő kézikönyveit kell bújni. 


Az SOL telepítése fürtre 

Az ismétlés elkerülése érdekében a telepítést úgy kezdjük, hogy 

már feltételezzük az MSDTC meglétét (lásd: Farkasokkal táncoló V.). 

1. Indítsuk el a telepítőt! 

2. Az ,Installation options" képernyőn válasszuk az 
Advanced option"-t! 

3. A következő képernyőn válasszuk a , Maintain a virtual 
server for failover clustering" lehetőséget! 

4. Itt adhatjuk meg a fürtből már ismert fogalmak tartalmát: 
virtuális kiszolgáló nevet választhatunk, IP-címet és alhálóza- 
tot adhatunk meg. 

5. A ,Cluster Management" képernyőn megtekinthetjük a fürt 
ja másolni az SOL állományokat. (Ezen a ponton lényeges eltérés 
tapasztalható az SOL Server és az Exchange között: az SOL mind- 
két állomást ,, megdolgozza", az Exchange Server viszont nem.) 

6. Végezetül meg kell adnunk a lemezerőforrásokat, amelyeket 
használni szeretnénk. Ha véletlenül a (uorum lemezét adjuk 
meg, akkor az SOL erőteljesen tiltakozik. Ez érthető, többször 
említettük a Ouorum és a clustercsoport sérthetetlenségének 
elvét. Ne telepítsünk semmit a Ouorumba! 

Ezzel végeztünk is. Aktív-aktív konfigurációnál hasonló módon 
hozhatunk létre újabb virtuális szervereket. 
Már a tervezés során igen fontos, a használat közben pedig kriti- 
kus lehet a házirend arról, hogyan 
költözzön az SOL virtuális szerver 
az egyik állomásról a másikra, s 
éppilyen fontos, hogyan költözzön 
vissza. Az át- és visszaköltözés u- 
gyanis megszakítja a meglévő kap- 
csolatokat, azokat tehát újra fel 
kell építeni. Mivel az ügyfelek olda- 
lán általában egy üzleti alkalmazás 
fut, nem mindegy, hogy miként va- 
lósították meg a fejlesztők a kiszolgálótól való elszakadást. Ha a 
kapcsolat nem épül fel automatikusan, esetleg újra kell indítani 
az ügyfélprogramokat. Ilyenkor érdemes a kevésbé terhelt idő- 
szakra időzíteni az erőforráscsoport visszatérését eredeti helyére, 
hogy ne okozzon újabb szolgáltatástkiesést a normális üzemre 
történő visszaállás. Ennek a megoldásnak is lehet hátránya, 
ahogy azt mindjárt látni fogjuk. 

Az átköltözési szabályokat befolyásolhatja az eltérő memória- 

mennyiség vagy memóriaigény a különböző állomásokon. 
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a Rosszul tervezett memóriahasználat SOL fürtözésnél 
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Az bal oldali ábrán azt látjuk, hogy az egyik állomáson bekapcsol- 
ták a 3 GB támogatást, a másikon nem. Az átköltözéssel erőtelje- 
sen vissza fog esni a teljesítmény, mert a második állomáson nem 
fér el" az SOL Server. A jobb oldali ábrán mindkét állomáson be- 
kapcsolták a 3 GB kapcsolót, ám az aktív-aktív konfiguráció állo- 
másainak teljes fizikai memóriája csak 4-4 GB, tehát egy átköltö- 
zés ismét teljesítménycsökkenést okoz majd. A tisztánlátás ked- 
véért: nem arról van szó, hogy az átköltözés nem történik meg, 
hanem arról, hogy visszaesik a teljesítmény, a rendszer intenzív 
lapozásba kezd. Még több virtuális SOL Servernél a probléma hat- 
ványozottan jelentkezik. Ez arra sarkallhatja a rendszergazdákat, 
hogy minél előbb állítsák helyre az eredeti állapotot, még az ügy- 
felek ismételt leszakadása árán is. Hosszú távon persze csak az 
alapos tervezés és előregondolkodás segíthet. 

Túlzás lenne azt állítani, hogy kimerítettük az összes tudnivalót 
az SOL és a fürt kapcsolatáról, de egy jó alapozást végeztünk. 
Befejezésül egy olyan alkalmazást veszünk górcső alá, amelyet 
nem is a Microsoft gyártott, mégis fürtre kész, és bizonyos hely- 
zetekben nélkülözhetetlen. 


Az ArcServe 2000 fürtözött környezetben 
Az ArcServe 2000 a Computer Associates által gyártott mentési 
rendszer. Azt mondhatjuk, hogy az ArcServe 2000 ma (majdnem) 
mindent tud, amit Windows környezetben egyáltalán tudni lehet, 
beleértve az olyan nyalánkságokat is, mint a szalagos könyvtárak, 
a RAID szalagok és a fürtök támogatása. Ez utóbbi nemcsak azt 
jelenti, hogy a szoftver lementi a fürthöz tartozó beállítások hal- 
mazát (a Owuorum lemezt és a regisztrációs adatbázis cluster ágát), 
hanem azt is, hogy az ArcServe maga is fürtözhető, így a menté- 
si feladatok minden körülmények között lefutnak, függetlenül at- 
tól, hogy épp melyik állomáson aktív egy erőforráscsoport. 
Ez a rövid leírás nem lesz elegendő ahhoz, hogy az ArcServe 2000 
minden tulajdonságát megismerjük, amelyet fürtözött környezet- 
ben magáról mutat. Annyit teszünk csupán, hogy a szoftvert a 
fürtre telepítjük, illetve megvizsgáljuk, milyen előnyök származ- 
nak a szolgáltatás megvalósításából. 
Az ArcServe 2000 fürtözése alapvetően három célt szolgál: 
1. A hálózaton található ArcServe ügynökök számára nagy rendel- 
kezésre állású ArcServe kiszolgálót biztosít. 
2. Szűk keresztmetszet esetén egy második ArcServe 2000 szer- 
vert lehet üzembe helyezni (aktív-aktív fürt). 
3. Meghibásodás miatt félbeszakadt mentési munkafolyamatokat 
automatikusan újra lehet indítani. 
Az ArcServe 2000-nek saját erőforrás DLL-je van, ám valami oknál 
fogva azt nem regisztrálja magától, tehát nekünk kell megtenni 
ezt a lépést. Ezen kívül végképp nincs segítségünk, az alapszoft- 
ver telepítése után ránk vár a fürtbe állítás feladata. A munka me- 
nete a következő: 
1. Telepítsük az ArcServe 2000-et az első állomáson a közös 
lemezre! 
Telepítsük a Tape Library opciót! 
Állítsuk be a közös mentési eszközt az állomáson! 
Telepítsük az ArcServe 2000-et a második node-on a közös 
lemezre! 
5. Ide is telepítsük a Tape Library opciót! 
6. Állítsuk be a közös mentési eszközt az állomáson! 
7. Ha Fibre channel környezetben dolgozunk,akkor mindkét 
állomáson állítsuk be az alábbi regisztrációs kulcsot: 


HKLMXSoftwareNX...NTapeenginetlConfig 


Érték: EnableSharedDevices: DUORD: 1 
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8. Adjuk ki a következő parancsot mindkét állomáson: 


cluster resourcetype "ARCserve"/create 


W/dllname:ascluster.d11 


9. Hozzunk létre egy erőforráscsoportot, vagy jelöljünk ki egyet, 
és készítsünk egy ArcServe erőforrást például így: 


cluster resource "My ARCserve" /create /group: 


B "Csoportneve" /type:"ARCserve" 


10. Tegyük függővé az erőforrást a fizikai lemeztől! 
11. Hozzunk létre egy általános szolgáltatást: 


cluster resource "My ARCserve Registry" /create 
$/group:"Csoportneve" /type:"Generic Service" 


12. Adjuk meg a szolgáltatás nevét: astapeengine! 
13. Adjuk meg az alábbi regisztrációs kulcsot: 


"SOFTUARENXComputerAssociatesVARCservelT Base" . 


14. Hozzunk létre egy megosztáserőforrást az alábbi paraméterek- 
kel: Megosztásnév "ARCserve$"! 

Elérési út: "S:(Program FilesYComputerAssociatesMARCserve". 
Ezzel elkészült a fürtözött ArcServe szolgáltatás. 
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For Help, press F1 
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5 Az ArcServe 2000 fürtkörnyezetben 


Véget ért az erőforrásokkal való ismerkedés. Legközelebb hibael- 
hárítással és egyéb kacifántos helyzetekkel foglalkozunk majd. 


Lepenye Tamás, MCSE 2000 
lepenyet omal.hu 


0292757 Exchange 2000 Setup and Installation Top Support Issues 


0239758 SRS Cant Run in Native Exchange 2000 Environment — 
0192708 Installation Order, Cluster Server Support for SOL or MSMO— 


0260758 Freguently Asked Ouestions - SOL 2000 - Failover Clustering 
0225092 "Evicting a Node in a Cluster Can Cause Problems in SOL 
0239885 How to Change Service Accounts on a SOL Virtual Server 
0243218 Installation Order for SOL 2000 Enterprise Edition 


0254321 Clustered SOL Server Dos, Dontts and Basic Warnings 
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Windows.NET Server Beta 3 / W1 


Windows.NET 


Server Beta 3 


Folytatjuk az előzetes szemezgetést a Windows.NET Server új funkcióiból, egyelőre még 
mindig a béta3 verziót használva - no és persze ismét teszünk egy kis kitérőt a belső 


Az ütemezés 

A legutóbbi tech.net magazinban jól körüljártam a Windows.Net 
Server korábbi kódnevének hiteles eredetét - éppen csak a leg- 
fontosabbról feledkeztem meg: nem derült ki, hogy hogyan is 
állunk az idővel, milyen fázisban van a fejlesztés, és mi az új 
termék megjelenésének várható ütemezése. 

A Windows.NET Server 2001. november 16. óta van béta3 állapot- 
ban, ez a 3590-es számú build. Ez az utolsó béta változat, ezután 
a tervek szerint két Release Candidate, az RC1 és az RC2 fog meg- 
jelenni, majd a végleges, RTM (Release to Manufacturing, gyártás- 
ba kerülhet) termékkód. A tervek szerint az RC1 2002 második ne- 
gyedévében, az RC2 a harmadik negyedévben, a végleges kód pe- 
dig ez év második felében várható. Valamikor, 

A Windows csapat belül természetesen ennél konkrétabb dátu- 
mokkal dolgozik. Nekik egész pontosan ki van adva, hogy az RC1- 
nek (tegyük fel, valós adatok hiányában pusztán példaként, kita- 
lált időpontokkal szemléltetve) június elejére el kell készülnie, az 
RC2 fejlesztésének mondjuk szeptember elején be kell fejeződ- 
nie, és lehet, hogy a Köztársaság kikiáltását ősszel itthon már 
egy végleges Windows.NET Server kóddal ünnepelhetjük. Lehet. 
Nem tudhatjuk. Ennek (és a fentieknek) a megértéséhez ismerjük 
meg egy kicsit jobban a fejlesztés menetét. 


A kutyaeledel 

Egyáltalán, mi is az a 3590-es build? Nos, a 
Windows fejlesztők napi ciklusban dolgoz- 
nak (jó példával elöljárva az MSF, a Micro- 
soft Solution Framework ajánlásait követik 
betű szerint). Minden nap lefordítják, 
összelinkelik az aznapi termést, ebből lesz 
az ún. napi build, azaz tulajdonképpen a 
Windows új változata. Másnap reggel minden tesztelő (hiszen kü- 
lön ilyen csapatok is vannak) gépére az előző napi build kerül fel- 
telepítésre, ezt kezdik nyúzni stressztesztekkel. Maguk a fejlesztők 
persze több gépen is dolgoznak, nekik nem kötelező a napi build- 
re átállni, és mindig azon dolgozni (pedig ez elég motiváló erő len- 
ne ahhoz, hogy ne kövessenek el túlzottan nagy hibákat... s 
Hibák természetesen keletkeznek (ezt azért látjuk kívülről is). 
Nem minden napi build stabil, a funkciók fejlődése mellett vi- 
szont ezeket a hibákat és azok javításának állapotát is 
nyomonkövetik, dokumentálják, sőt előre tervezik, mit, mikor, 
melyik fázisban, milyen más funkciók hibáival együtt javítanak 
majd (priorizálva, egy változáskezelési módszert használva, mely- 
ről szintén az MSF-ben olvashatunk). 

Pár napos, esetleg pár hetes időközönként egy-egy build-ről ki- 
mondatik, hogy az stabil - ezeket az oprendszer változatokat at- 
tól függően hívják ún. IDW vagy IDS buildeknek, hogy mennyi- 
re gondolják őket stabilnak. A rövidítés az Internal Develop- 
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ment Workstation/Server kifejezést takarja, amiből látszik is, 
hogy ez az a belső kutyaeledel amit a fejlesztőknek saját ma- 
guknak kell megenniük (eat your own dogfood). A Workstation 
jelentése itt nem az oprendszer típusára vonatkozik. Egy olyan 
alacsonyabb" minőségi szintű változatot jelöl, ami elég stabil 
ahhoz, hogy a belső Microsoft hálózaton saját számítógépen le- 
hessen használni. Az IDS változatban a Server szó magasabb mi- 
nőségre, stabilitásra utal, amely ahhoz szükséges, hogy ezt a 
verziót az emberfia nyugodt lélekkel fel merje tenni az éles 
üzemben működő kiszolgálójára. A legfrissebb IDW vagy IDS 
build tehát nem a legfrissebb napi változat, hanem mindig a 
legutóbbi stabil build, amihez, mint kályhához vissza lehet 
menni. Későbbi, nem közbülső buildekkel is kísérletezgethetnek 
a vállalkozóbb szelleműek, azonban esetleg érdekes jelenségek- 
kel kell számolniuk - ezek neve éppen ezért TST, azaz teszt 
build. (Egyébként meglehetősen leegyszerűsítettem a build- 
folyamatot, ennél azért komplexebb a dolog...) Ahogy írtam, éles 
környezetben senkinek sem kötelező az átállás a legfrissebb sta- 
bil buildekre, de a korábban már említett ,együk meg azt a ku- 
tyaeledelt, amit főztünk" jelmondatot követve sok fejlesztő 
használ a belső szlengben ténylegesen , dogfood"-nak nevezett 
munkaállomásokat és szervereket. Az IDW, 
IDS buildek nem nyilvánosak (mint arra az 
Internal szóból is következtethetünk), a 
külső bétatesztelők sem érhetik el vagy 
tölthetik le ezeket. Az egyéb napi 
buildekhez a Microsoft belső hálózatán is 
csak azok juthatnak hozzá, akiknek az ún. 
buildszerverekhez hozzáférése van (a tech- 
nikai embereknek ezt általában megadják). 
Jelen sorok írásakor egyébként a legfris- 
sebb Windows.NET Server TST build száma 3629, a legfrissebb 
IDW a 3628-as, az IDS pedig a 3621-es. 


A béta 

Mit jelent akkor tulajdonképpen a béta? Nagyobb mérföldkő a fej- 
lesztés menetében. Mérföldkőhöz akkor érkezünk, ha a projektdo- 
kumentum szerint valamilyen követelmények teljesülnek - ez bár- 
mi lehet, általában a funkcionalitás valahány százalékának 
elérését, bizonyos konkrét funkciók megírását jelenti, teljesen 
projektfüggő. Az első bétaváltozatnál szoktak elindulni az ún. 
technikai bétateszt programok, amikor a szokásos belső tesztelés 
mellett már külső tesztelőket is bevon a Microsoft. Külső techni- 
kai bétatesztelőnek bárki jelentkezhet, ám a bekerüléshez elég sok 
feltételnek eleget kell tenni. Valójában a technikai bétatesztelő 
cím nagyon sok kötelezettséggel is jár. Ha valaki ilyenre jelentke- 
zik, akkor vállalnia kell, hogy egy-egy funkcióterületet szisztema- 
tikusan tesztel, és a hibákról (reprodukálható környezettel és hiba- 
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leírással) részletes beszámolót ír (a beépített error reporting már 
sokat segít ebben, azonban nem mindenre terjed ki a működése). 
Sokszor felmerül a kérdés, hogyan lehet valaki hivatalos bétatesz- 
telő - nos, a fentiek fényében rávilágítanék arra, hogy a Kedves 
Kollégák általában nem tesztelni akarnak, mivel ez elég nagy kö- 
töttséggel jár, a legtöbbször pusztán a bétaváltozatokhoz szeret- 
nének hozzájutni, és próbálgatni, tanulgatni az új dolgokat. 
Minderre van lehetőségünk, a technikai bétatesztelés mellett egy 
idő után a bétaprogram nyilvános lesz (általában inkább már a 
Release Candidate-ek megjelenésekor). Ilyenkor a Microsoft sok- 
szor fűnek-fának osztogatja az időbombás béta vagy RC változa- 
tokat, gyakran magazinok CD-mellékletekként is megjelennek 
(akár nálunk is, ha emlékszünk a Windows 2000 esetére). 

Attól a lehetőségtől ugyan elesünk, hogy a közbülső IDW/IDS 
buildekhez hozzájussunk, ám általában jobb a bétákat használni, 
mivel azok érezhetően stabilabbak, mint a közbülső stabil buildek. 
Az utóbbi években már megszokott lett, hogy kb. a béta3-as Win- 
dows változatok már olyan mértékben stabilak, hogy éles környezet- 
ben is használhatók. A Microsoft hálózatán belül már minden tarto- 
mányvezérlőn megtörtént az áttérés Windows.NET Server Beta3-ra, 
ezen kívül az ún. Joint Development Program- 
ban (JDP - az áprilisi Whistler cikkben erről már 
esett szó) szereplő vállalatoknál, szervezetek- 
nél is működnek éles környezetben .NET 
Server Beta3-ak - sőt, ilyenre nálunk is volt 
példa a Windows 2000 idején, egy hazai táv- 
közlési cég működő számlázási rendszerében 
futottak Windows 2000 Beta 3 Serverek. 
Hogyan jussunk hozzá tehát a bétákhoz? Eb- 
ben a TechNet (nem a magazin, hanem a CD!) 
vagy MSDN előfizetés szokott segíteni, hiszen ezekkel a termékbé- 
tákat is megkapjuk. Vigyázzunk, nem mindegyik típussal! A TechNet 
esetében csak a TechNet Plus előfizetés esetén jönnek a béták, az 
MSDN weboldalon pedig egy frappáns összefoglalót találunk arról, 
melyik előfizetés-típussal pontosan mit is kapunk meg [1]. 


A Release Candidate 

Már csak egy kérdésre kell válaszolnunk: mit takar a Release 
Candidate kifejezés? Végül is a béta egy-egy nagyobb mérföld- 
követ jelent, akkor vajon az RC egy még nagyobb mérföldkő len- 
ne? Nos, valahogy így van. Korábban, 4-5 évvel ezelőtt nem lé- 
tezett a Release Candidate kifejezés, csak alfák és béták voltak. 
Az RC neve már sokat elárul arról, hogy mit is jelent a fogalom 
- magyarul valahogy úgy fordíthatnánk, hogy ez a változat je- 
tölt, esélyes arra, hogy végül is kimondasson róla: ő a végleges, 
kész változat, az ún. Release. (Érdekes, hogy bár a release szó is 
az MSF-ből jön, és szó szerint termékkibocsátást jelent, az 
Internetes szlengben is meglehetősen elterjedt: a cracker, ripper 
csapatok is ezt használják a feltört szoftverek, videók, zenei anya- 
gok kiadására. Honosított és igésített változata sem idegen már a 
magyar fülnek, teljesen hétköznapinak számít a , warezt", 
,gamezt" (összefoglaló néven stuff-ot, stuffát azaz stuffezt) 
arilízelni" kifejezés. Örvendetes, hogy ilyen helyekre is eljut a 
Solutions Framework terminológiája... €5). 

Az RC-t az is megkülönbözteti a bétáktól, hogy RC fázisban már 
csak hibajavítás folyik, újabb funkciók már nem kerülnek be a 
termékbe. Kifelé viszont még ebben a fázisban is kerülhetnek. 
Bétában ez teljesen természetes, akár technikai, akár marketing- 
okokból kieshetnek funkciók belőle. (Lehet pl., hogy az adott 
funkciókészlet annyira hasznos, hogy érdemesebb külön termék- 
ként, plusz pénzért árulni. Ez történt pl. a COM4- terhelésmegosz- 
tással, mely a farmkezelési funkciókkal együtt még benne volt a 
Windows 2000 Advanced Server Beta 3-ban, de időközben kikerült 
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az oprendszerből, és külön szervertermékként került 
forgalomba: ez az Application Center Server 2000). 
Éppen ezért hangsúlyozom folyton a cikkekben, 
hogy egyáltalán nem biztos, hogy a most kezünkben 
lévő, szemünkkel tapasztalt funkciók a végleges termékben is 
benne lesznek. Hasonló okok (de inkább a minőségi mércék) az 
időzítést is befolyásolhatják. Brian Valentine (szintén ismerős sze- 
mély az áprilisi tech.net számból) már a Windows 2000 idején is 
széles (belső) plénum előtt közölte, hogy addig nem adja ki a ke- 
zéből a kódot, amíg nincs meggyőződve a stabilitásáról - bármek- 
kora nyomást is gyakorol rá a marketing, a sajtó és a közvélemény. 
Ez azért valahol - valljuk be őszintén - dicséretes. 

Egy-egy hiba kijavítása az RC fázisban is csak több napi build 
ciklusa alatt zajlik le, így ha több kiemelt hiba is összehangol- 
tan javításra kerül egy buildben, az eredmény újabb mérföldkő, 
azaz újabb RC lesz - ez történik majd a .NET Server RC1 és RC2 
változatában is. A végleges kód belső neve az ún. RTM, a 
Release To Manufacturing kifejezés rövidítése. A fejlesztőcsapat 
ekkor adja hivatalosan gyártásba a legfrissebb IDS buildet (most 
már értjük, mit jelent -— ekkorra már RTM szóval is illetik) , tehát 
ebből indulnak meg a lemezprések. A Win- 
dows XP RTM idején ez volt az a kicsit túl- 
spirázott pillanat, amikor helikopterekkel 
vitték iziben, melegen az arany CD lemezre 
kiírt végleges kód mesterpéldányát a nagy 
OEM gyártóknak (Compag, HP, Dell, IBM, 
stb,) hogy beindulhassanak a gyártósorok. A 
bolti megjelenés (az ún. dobozos termék el- 
készülte) ilyenkor még akár 4-6 hetet is vá- 
rat magára, mert a doboz összeállításhoz és 
gyártásához (dokumentáció, csomagolás, CD), illetve a terítéshez, 
szállításhoz ennyi időre van szükség. A nagy, népünnepély szintű 
termékbejelentő eseményekkel éppen ezért mindig megvárja a 
Microsoft a doboz elkészültét is, hogy a bejelentésen legyen va- 
lami materiális reprezentációja annak, hogy íme, itt a termék, el- 
készült, megérkezett (ha ekkor feltartjuk a magasba az új Windows 
dobozt, azért ügyeljünk arra, hogy ne fordítva tegyük, ez sokat tud 
rontani a hatáson... €) (Tapasztalat? — a szerk.) 

Térjünk át lassan ismét az új funkciókra - szokás szerint kezd- 
jünk megint az Active Directoryval. 


A küzdelem 

Egy tipikus hollywoodi forgatókönyvben a legyőzött ellenfélnek 
illendő kevéssel a film vége előtt, avagy a folytatásban feltá- 
madnia, hogy újra le lehessen győzni. A Windows 2000 Active 
Directory is produkálhat elvileg ilyen horrorisztikus jeleneteket 
- egy objektum törlésénél ugyanis (mint az ismeretes) nem fi- 
zikailag töröljük az adott objektumot az adatbázisból, csupán 
egy sírkövet (tombstone) replikálunk szerte a világba, melyek 
majd a mögöttük lévő objektumokkal együtt a garbage collec- 
tion metódus később szépen kitakarít, ahogy azt már az Exchange 
5.5 óta megszoktuk. A sírköveknek élettartamuk van (TTL - Time 
To Live), azaz egy idő után eltűnnek, maguk után rántva a ta- 
kart objektumot. Ha ez az időtartam jóval nagyobb, mint teljes 
rendszerünk legnagyobb replikációs késleltetése (azaz előbb-utóbb 
a legtávolabbi helyre is biztosan eljut ez a sírkő, mielőtt kihalna) , 
akkor minden egyes tartományvezérlőről valóban törlődik az 
összes objektumpéldány. Gond csak akkor van, ha túl kicsire 
vesszük ezt a paramétert (tombstone lifetime). Ez viszont már a 
mi hibánk, és egyébként is csak hangolási kérdés. 
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[/) j Mi történik azonban akkor, ha egy tartományvezér- 
lő huzamosabb ideig ki van valahol kapcsolva (vagy 

ami a szempontunkból ugyanaz - jó hosszú ideig 

Hű nincs hálózati kapcsolata egyetlen más DC-vel sem)? 
Lehetséges, hogy ezalatt a kieső idő alatt a többi DC-n tö- 
rölt objektumok sírköveinek élettartama már lejárt, eltűntek, így 
nincs mit replikálni. Ilyen esetben fordulhat elő, hogy a semmi- 


feltámadt objektumokat. 


Windows NT4 Domain Controller emuláció 
Már hallom is a Kedves Olvasót, amint felkiált: , Hiszen ezt is- 
merem! Ez már Windows 2000-ben is volt!" 
Higgadjunk le, kérem. Nem a PDC Emulátorról van szó. 
Korántsem. A probléma a következő (0298713): 
Egyelőre még NT4-es tartományunk van (végre egy ízig-vérig magyar 
forgatókönyv) (nem valami Amerika... — a szerk. gyenge megjegyz.). 
Kliensoldalon (az újonnan vásárolt gépeken) viszont már elkezd- 
tünk Windows 2000-re, vagy éppenséggel Windows XP-re átállni. 
Csakhogy, amint elhatározzuk, hogy átállunk Active Directoryra, 
és annak rendje-módja szerint Windows 2000-re frissítjük az 
NT4 PDC-t, abban a szent pillanatban az összes Windows 2000 
Professional SP2 és Windows XP Pro kliens mindenfajta ügyes- 
bajos címtárral kapcsolatos forgalma az egyetlen Windows 2000 
DC-hez fog becsapódni. Bármennyi NT4-es BDC legyen is még a 
láthatáron (akár a helyi LAN-on, ugyanazon a telephelyen), a 
2000/XP kliensek ezután csak a Win2000-es (vagy .NET Server- 
es) DC-vel hajlandóak szóba állni. Ha nincs ilyen, akkor jó az 
NT4 is. Ha viszont akár egyetlen is van a közelben (telephelyen), 
akkor csak ő jó. Ezek a kliensek már csak ilyenek. By design. 
Ha bírja ez az egy DC a terhelést (no itt lesz valami amerikai a 
történet - Magyarországon bírni fogja...), semmi gond. Ám ha 
nem bírná, rábírhatjuk a .NET Servert, hogy (legalábbis DC szem- 
pontból) tegyen úgy, mintha NT4 lenne. PDC vagy BDC? - jöhet 
a kérdés. Ez most mindegy, mert nem a replikáció, hanem egyéb 
címtárműveletek (hitelesítés, LDAP lekérdezés, stb.) szempontjá- 
ból fog NT4 akcentussal beszélni. Mindezt a registryben lehet 
beállítani, és csak kétállású a kapcsoló (ki és be - tehát nincs 
PDC és BDC, erre továbbra is van PDC emulátor FSMO szerepkör). 
Ez a lehetőség egyébként SP2-től kezdve a Windows 2000 
Serverben is használható. Ha félünk a túlterheléstől, minden fris- 
sített DC-n bekapcsolhatjuk az 


Windows 2000/.NET Serveren persze van PDC Emulator szerepkörünk, 
de csak egy darab. (Ezért hívják single operations masternak, ugye- 
bár.) Ha több telephelyen (de egy tartományban) szeretnénk az al- 
kalmazást használni, akkor azok mindenütt igényelnének egy NT4 
PDC-nek tűnő dolgot. Persze az ntdsutil seize parancsával elvileg csi- 
nálhatunk PDC Emulator-ból is többet, sokat, bármennyit. (Ezt hívják 
hackelésnek. Már a gondolat is halálos! Felejtsük is gyorsan el!) 


0) ből egyszer csak régen törölt objektumok jönnek elő. Feltámad- — Windows 2000 SP2-vel és .NET Serverrel viszont több DC-n is be- 
Z3 nak, újra le köll győznie őket a rendszergazdának. Feltéve, ha — kapcsolhatjuk az NT4 emulációt, és ki tudja, lehet, hogy ennyi 
oO észreveszi őket. Nos, igen, ez elég komoly biztonsági rés lehet. — elég is az alkalmazásnak, ezzel működni fog. Nem kell várni, míg 
ö A .NET Serverben a repadmin eszköz megoldást ad erre a prob- a fejlesztők átírják, tesztelik, ami jó időbe telik (és általában 
- lémára: azonosíthatjuk és törölhetjük az ilyen semmiből újra — meg is akadályozza erre az időre a vállalaton belül a Windows 


2000 Serverre való átállást, hiszen ilyen egyedi fejlesztéseknél ál- 
talában kulcsfontosságú üzleti alkalmazásokról van szó). 


Biztonság 

A Windows.NET Serverben a biztonsági szolgáltatások területén 
is sok apró újdonság, továbbfejlesztés található. Az újdonságok- 
ról már olvashatunk is egy külön műszaki tanulmányt [2]. 
Roppant érdekes újdonság az ún. Authorization Manager MMC 
Snap-in (érdekességét az is fokozza, hogy a béta3-ban ezt még 
nem találjuk meg, későbbi buildekbe került csak bele...). Ez egy 
olyan felület, mellyel a jogosultságokat ténylegesen a céges műkö- 
désre leképezve, üzleti folyamatok szerint szabályozhatjuk. Szerep- 
köröket használhatunk, melyek a felhasználók valós életben betöl- 
tött munkakörével azonosak (pl. főnök, beosztott, pénzügyes, mar- 
ketinges), műveleteket definiálhatunk a szerepkörökhöz, melyeket 
engedélyezünk vagy tiltunk. Mindezt persze eddig is megoldhattuk 
csoportokkal, de a leghasznosabb funkció az, hogy az erőforráso- 
kat, objektumokat többféle halmazba, ún. scope-ba rendezhetjük. 
Ezeknek a halmazoknak összevontan kezelhetjük a hozzáférésért és 
a megfelelő szerepkörökhöz jogosultságokat rendelhetünk. 
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NTA emulációt - a terhelés pedig 
megoszlik. Egész addig így 


Az API például olyan 


o Az Autorization Manager MMC Snap-In felülete 


hatékonyabban össze- 
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új függvényeket is 


hagyjuk a rendszert, amíg kettő 


tartalmaz, amelyekkel 
az egyes felhasználókhoz 
(szerepkörhöz) tartozó 


vagy több szervert nem frissí- 
tünk, s amikor már úgy gondol- 
juk, hogy bírni fogják a DC-k a 
kliensek rohamát, kikapcsoljuk 
az NTA emulációt. 

Ahogy említettem, ekkora ter- 
helés nem valószínű hazai kör- 
nyezetekben, egy telephelyen. 
Miért lehet ez mégis hasznos 
hazánkban? Szerte az országot járva hallani híreket olyan egye- 
di fejlesztésű, (de akár még gyári) eredetileg NT4-re írt vállala- 
ti alkalmazásokról, amelyek valami (teljesen ismeretlen) fejlesz- 
tői hóbort miatt NT4 PDC-t követelnek. 


jogosultságok 


gyűjthetők 


vorking with 
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(amit a béta3-ban még hiába keresünk... ) 


Mielőtt ráfognánk az új MMC beépülő modulra, hogy csak mar- 
keting-csingilingi, tudnunk kell, hogy mögötte egy ún. Autho- 
rization API készlet is megjelent, melynek feladata, hogy köz- 
benső rétegként eltakarja a hozzáférés-vezérlési listák (ACL-ek) 
és egyes rendszererőforrások objektumszerkezetének működését 
olyan absztrakciós felületet képezve, ami pl. a fenti szerepkö 
ket és objektum scope-okat biztosítja. Az API például olyan új 
függvényeket is tartalmaz, amelyekkel az egyes felhasználókhoz 
(szerepkörökhöz) tartozó jogosultságok hatékonyabban össze- 
gyűjthetők - így régi nagy álmunk is teljesül, egyetlen rendszer- 
hívással megkaphatjuk, hogy adott felhasználónak az NTFS fájl- 
rendszeren milyen jogai vannak - anélkül, hogy olyan szkriptet 
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vagy programot kellene írnunk, ami végigfut az összes könyvtá- 
ron és fájlon, hogy megnézze az ACL-eket. (Ilyen programról ol- 
vashatnak a 24. oldalon, a Szerszámosláda rovatban. ) 


Headless Server 

Pasguale DeMaio egy nagyon szerény francia srác, akinek őszintén 
szólva nem irigylem a helyzetét. Ő a Microsofton belül a .NET 
Server távoli felügyeleti technológiáinak, az ún. Headless Server 
fejlesztésnek (tech.net magazin első Whistler előzetes) felelős 
Program Managere. Főnökei, kollégái, beosztottjai, de még a ba- 
rátai is csak úgy emlegetik - a Headless Program Manager... 

Itt talán nem is az a legfontosabb fejlesztés, hogy monitor, bil- 
letnyűzet, egér nélkül használhatjuk a rendszert. A távoli felügye- 
letnek két nagy területe van: az ún. in-band és az out-of-the- 
band, azaz a sávszélességen belüli és kívüli felügyelet. Az esetek 
és az idő 9890-ában sávszélességen belül akarunk felügyelni, erre 
ismerjük az eszközöket - terminálszolgáltatás, MMC modulok tá- 
voli csatlakozása, távoli registryszerkesztés, stb. Az érdekes és új 
dolog a sávszélességen kívüli, ún. Emergency Management 
System, EMS. Számos hardver akkor is támogatja már a távoli 
felügyeletet (egy külön szervízprocesszorral, külön hálókártyával, 
vagy éppen modemes behívás lehetőségével magába a PC vasba), 
ha a hálózat és így a gépen lévő oprendszer nem elérhető. A 
Windows.NET Server szabványos felületen (ez az EMS) hozzáfér- 
hetővé teszi az oprendszert akkor is, amikor egyébként hálózatról 
még, vagy már nem érnénk el - boot folyamat alatt, a telepítés 
karakteres képernyő részénél, RIS telepítés alatt, blue screen ké- 
pernyőnél. A hangsúly itt a szabványosságon van. Egyes gyártók 
(pl. Compag, HP) eddig is árultak olyan szervízkártyákat, amelyek 
speciális eszközillesztőivel szintén elérhető volt távolról grafikus 
felület, ezek azonban egyedi, gyártó- (és szervervas-) specifikus 
megoldások voltak, és így meglehetősen sokba kerültek. 

Az EMS a szabványos VT-UTF8 terminálprotokollt használja, mely 
visszamenőlegesen kompatíbilis a jól ismert VT100-zal (színeket, 
nem angolszász karakterkészleteket és egyéb nyalánkságokat támo- 
gat még pluszban a VT100-hoz képest). Ha tehát van egy VT100 
terminálunk (Valljuk be, sokan őrzünk ilyet otthon nosztalgiából 
csak azért, hogy megmutathassuk a gyerekeinknek, hogy a Mátrix 
c. filmben micsoda anakronisztikus ellentét a VT-100 monitorhoz 
csatlakoztatott Microsoft Natural Keyboard. A terminál az terminál. 
Annak a billentyűzet is része. Szentségtörés ilyen erőszakot tenni 
vele...), vagy egy VT100 illetve VT-UTF8 terminálemulátor-szoft- 
verünk, soros porton keresztül - hardvertámogatás esetén egy 
másik hálókártyán vagy modemen keresztül - távolról elérhetjük 
a gépünket, és matathatunk akár a BIOS-ban is. Amennyiben a 
hardver kiadja ezt a terminálkimenetre (ehhez a .NET Server-nek 
sok köze nincs)... A VT-UTF8 csatlakozáson keresztül dolgozha- 
tunk a korábban szintén említett SAC konzollal (Specialty 
Administration Console), mely hasonlít a Recovery Console-hoz, 
ám sokkal kevesebb (kb. 8-10) utasítást támogat. Elindíthatunk 
viszont más alkalmazásokat belőle (pl. cmd.exe-t, normál parancs- 
sori felületet), amivel a helyzet rögtön sokkal rózsásabbá válik, 
hiszen akár szkripteket is futtathatunk így távolról egy olyan gé- 
pen, amit egyébként a hálózaton keresztül nem érünk el. 
Vállalati felhasználóknak (zárt szerverszobákhoz) és kisvállala- 
toknak (Internetszolgáltatónál hosztolt gépek) is hasznos ez a 
funkció. A Netacademia munkatársainak - hogy egy valós élet- 
beli példával szolgáljak - sokszor gondot okoz, hogy a BIX-re (a 
hazai Internet főgerincre) közvetlenül csatlakozó www.netaca- 
demia.net szerveren (ez a jó tulajdonság az itt működő hivata- 
los magyar Microsoft letöltőközpont sebességén is tükröződik) a 
két felhasználós admin módú terminálszolgáltatásban , bentra- 
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gadnak" a felhasználók, és két kapcsolat után már 
többen nem csatlakozhatnak. (Ha már a konkrétu- 
moknál tartunk: nem a termék a hibás, hanem jelen 
cikk szerzője szokta magát bennfelejteni — a szerk.) A 
terminál MMC, amivel ki lehet dobni az embereket, RPC-vel 
kapcsolódik, ami persze nem megy át a tűzfalakon. Ilyenkor te- 
hát trükkös módszereket kell használni a kiléptetéshez (vagy 
csak a kicsatlakoztatáshoz) , hogy egyáltalán távolról felügyelni 
lehessen a gépet. Más esetben ez a patthelyzet odáig is fajul- 
hat, hogy nincs más lehetőség, újra kell indítani a gépet, hogy 
visszakapjuk a távoli kontrollt felette. Munkaidőben persze oda 
lehet telefonálni a szolgáltatónak, hogy (megfelelő élőszó alapú 
hitelesítési protokoll használata után) nyomja meg a reset gom- 
bot - éjszaka és hétvégén ez persze nehézkes. 

Piaci forgalomban elérhetőek egyébként olyan ún. terminálkoncent- 
rátorok, amelyekbe modemen keresztül betárcsázva megkapjuk a 
VT-UTF8 konzolt. A koncentrátor soros porton több géphez is csat- 
lakozhat, melyek között váltogathatjuk a modemes terminálkapcso- 
latot. A soros vonalon kívül a koncentrátor a 220-as vezetékeket is 
koncentrálja magában, és minden ilyen tápkábelhez gépenként 
megszakítót is tartalmaz. A megszakítót egy VT-UTF8 konzol pa- 
ranccsal vezérelhetjük, azaz ha minden szakad, távoli emberi segít- 
ség nélkül telefonon keresztül adhatunk hard resetet a gépnek. 

Ha már a terminálszolgáltatásnál járunk, a Windows 2000-es 
Terminal Connection Manager MMC-t nem igazán tudjuk lebe- 
szélni arról, hogy indítás után az összes tartomány összes gépét 
felsorolja nekünk csatlakozási lehetőségként a bal oldalon. Ha vi- 
szont egy konkrét szerverhez akarunk kapcsolódni, azt nem tud- 
juk így megadni (csak ha terminál ablakból indítjuk az MMC-t) . Én 
pórul is jártam emiatt a minap, mert nem tudtam a fenti okok- 
ból bentragadt admin kapcsolatokat kilőni (vagy csak lecsatla- 
koztatni) RAS-on keresztül - a távoli gépem ugyanis nem volt 
tagja egy tartománynak sem, munkacsoportban ment. Nekem is 
trükköznöm kellett. Mindenesetre nem grafikus felületről oldot- 
tam meg a problémát (nekem legalább volt RPC-m, mivel közvet- 
lenül a céges hálózatba tárcsáztam be). 

Mindezt azért említem, hogy tudjuk értékelni: a .NET Serverben a 
terminal MMC alapértelmezésben nem sorolja fel a tartományokat 
és gépeiket, illetve bármikor megadhatunk NETBIOS, FODN néven 
vagy IP-címen egy terminálszervert, amit felügyelni akarunk. 
Folytatás júniusban - maradt még téma bőven, és részben még 
az előző számban igértekkel is adós maradtam... 


Horváth Tamás 
MCSE2000 
Microsoft Magyarország 


A fent közöltek a szerző saját véleményét tükrözik, és semmilyen módon 
nem tekinthetők a Microsoft Corporation hivatalos álláspontjának. 
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9 Metadirectory 
Services (II. rész) 


A legutóbbi Tech.net magazinban áttekintettük, hogy általában milyen elvárásaink lehetnek 
egy metacímtár szolgáltatástól. Most konkrétan a Microsoft Metadirectory Service 
(MMS 2.2) működésével ismerkedhetünk meg. 
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Zoomit és Microsoft 

A Windows 2000-ben megjelent Active Directory nagyvállalati 
címtárszolgáltatás belső kifejlesztése mellett a Microsoft a meta- 
címtár-szolgáltatásra, a korábban tárgyalt identitáskezelési problé- 
mákra is megoldást kívánt adni. Ezen megfontolásból 1999 júliusá- 
ban megvásárolta a ZOOMIT céget, mely akkor a metadirectory 
megoldások területén piacvezetőnek számított. Az akvizíció ered- 
ményeként a Microsoft, Windows 2000 Server platformon a 
címtárszolgáltatással kapcsolatos biztonsági, nagyvállalati és me- 
tacímtár szolgáltatásokat egyaránt biztosítani tudja. Idővel persze 
a rendszer (Microsoft Metadirectory Services néven) beépül majd a 
Windows elosztott rendszereinek sorába. Az MMS tehát egy, a piac- 
ra már bevezetett termék. Hosszú élettörténettel és kiterjedt nagy- 
vállalati vásárlói körrel rendelkezik - ez megnyugtató. A továbbiak- 
ban a jelenlegi változatról, az MMS 2.2-ről lesz szó. 
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5 A Zoomit cég VIA termékének története 


Microsoft Metadirectory Services 2.2 

Az alábbi ábrán koncepcionális szinten láthatók a metacímtár-szol- 
gáltatás komponensei: 

"0 csatolt (forrás) címtár (connected directory), 

"0 Meta Engine, 

"2 konnektor névtér (connector namespace), 

"I metaverzum (metaverse), 

"0 kliens (client). 


Metadirectory 


Metaversum . Konnektor 


névtér 
[ÜL EECI 2— 
LDAP 














0 A Microsoft Metadirectory Services felépítése 
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Microsoft 


A fenti illusztrációban a metacímtárt LDAP-on keresztül elérő ügy- 
fél az MMS-ben lévő Compass nevű kliensszoftver, de az MMS a 
HTTP (tehát web böngészővel történő) elérést is támogatja. 


A metacímtár névterei 

A metacímtár két névtérre oszlik: 

A konnektortér az a hely, ahová a csatolt címtárból importált elemek 
megérkeznek. Minden egyes csatolt címtár saját területtel rendelke- 
zik a konnektortérben. A konnektortér speciális objektumok, ún. kon- 
nektorok és diszkonnektorok gyűjteménye. Ezek utóbbiak közt az a 
különbség, hogy a konnektor rendelkezik egy attribútummal, mely a 
hozzá kapcsolt metaverzum-objektum (metaobjektum) Distinguished 
Name (egyedi, megkülönböztető név) paraméterét tartalmazza. A disz- 
konnektornak ugyanez a paramétere nincs kitöltve, így valójában 
csak helyet foglal egy bejegyzés számára a csatolt címtárban - a hi- 
vatkozott metaobjektum lehet hogy létezik, lehet hogy nem. A kon- 
nektorok teremtik meg a kapcsolatot a metaobjektumok és a csatolt 
címtár objektumai között, le- 


hetővé téve köztük a szink- , A metaverzum a 
ronizációt és az attribútu- 


mok áramlását. A diszkon- címtárnak az a 
nektorok az ilyen jellegű része, mely a külön- 
kommunikációt megállítják. ezi k 2 

A konnektortér objektumai a böző címtárakból 
metacímtár-hierarchiában aZ egyesítés soran 


mindig a Management Agents létrejött objek- 
bejegyzés alatt jelennek 


meg. Általában kevés atti. tumok közös képét 
bútumuk van kitöltve, első- tárolja. 

sorban közvetítőként működ- 

nek a metaverzum és a csatolt címtár között. 

A metaverzum a címtárnak az a része, mely a különböző címtárak- 
ból az egyesítés során létrejött objektumok közös képét tárolja. A 
metaverzum tartalmának legnagyobb része a csatolt címtárakból 
származik, de lehetőség van a metaverzumba való közvetlen adat- 
bevitelre az objektumhoz kapcsolódó címtár megadása nélkül is. 





ZUUSé:. BUZ. 


Nézzük az alábbi ábrán szereplő névteret: 


TAMA 





Konnektortér 


A Kovács Józsefet képviselő 
metaobjektum 


5 A névtér (Namespace) 


Az ábrán a Kovács Józsefet reprezentáló metaobjektum egyaránt tar- 
talmaz tulajdonságokat a Microsoft Exchange-ben és a Windows NT- 
ben található, Kovács József objektumból. Valamikor a Kovács Józse- 
fet reprezentáló Lotus Notes-béli objektum szintén kapcsolódott a 
metaverzumban lévő reprezentációhoz, ezt azonban mára szétkap- 
csolták. Kovács József nem szerepel a Banyan Vines címtárban és 
nem vesz részt a TAMA (Together Administration Management Agent) 
által megvalósítható felvétel/távozás szituációban sem (a TAMA-t ké- 
sőbb részletesen tárgyaljuk — ne keverjük a SAMA-val, ami egy exkluzív 
szemüvegkeret márka www.samaeyewear.net — a szerk. megj.) 

A következő ábrán látható Compass kliens képernyőképek a két 
névteret egymás mellett mutatják. Az elsőn a metaverzum képe lát- 
ható, mely a hierarchia csúcsával (The Known Universe) kezdődik, és 
a fa Daniel Penn bejegyzésig vezető ágait mutatja. A képen látható 
utolsó bejegyzés az mdserver, mely a metacímtár szervert jelképezi 
- ennek szerkezetét mutatja a második képernyőkép. Itt láthatóak 
a Management Agentek (MA-k) és azok konnektorterei. Szintén itt 
található a metadirectory számára létrehozott séma, mely a repliká- 
ciós és időzítési információkat tartalmazza, és ahol telepítéskor a 
teljes metadirectoryt kezelő Administrator bejegyzés létrejön. 


5 A metaverzum és a konnektor névterek 


Az illusztráción látható, hogy az Autók (Autos) objektum (mely egy 
osztály) és a Daniel Penn objektum (egy személy) a konnektortér- 
ben és a metaverzumban egyaránt léteznek. A konnektortérben ta- 
lálható példányok konnektorok (meglepő módon), a metaverzum- 
ban található reprezentációjuktól egy ikon különbözteti meg őket. 
A csatolt címtárat kezelő konnektortér a , Humongous Insurance 
HR" nevű MA, vagyis egy ügynök, azaz management agent. Más 
MA-k szintén tartalmazhatnak konnektorokat a saját címterükben 
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létező Daniel Penn reprezentációkra. A metaverzum- 
ban található Daniel Penn objektum ezekből mind tar- 
talmazhat bizonyos attribútumokat. 


Management Agent-ek (MA-k) 

A Meta Engine (metamotor) vezérli a metacímtár és a csatolt cím- 
tárak közti kommunikációt. Minden információt tartalmaz, mely az 
objektumok létrehozásához, törléséhez, tulajdonságaik integritásá- 
nak és történetüknek fenntartásához szükséges, és megvalósítja a 
tulajdonságok birtoklását. A tulajdonságok leírásához szükséges 
Meta Engine utasításokat a Management Agentek tartalmazzák. Ez 
utóbbiak speciális objektumok, melyek a csatolt címtárak integrá- 
ciójához szükséges paramétereket, szkripteket, átalakítási szabá- 
lyokat, attribútumbirtoklási ás áramlási szabályokat írják le. 

Az MA-k kezelik a metadirectory kapcsolónévtere, a csatolt címtá- 
rak és a metaverzum közti relációkat mind az objektumok, mind az 
attribútumok szintjén. Az MA-k helyileg az MMS szerveren 
leledzenek, és (csatolt) címtárspecifikusak. Egy MA belső konfigu- 
rációja tehát minden csatolt címtár esetében különböző. Fontos 
megjegyezni, hogy az MMS semmilyen szoftverkomponens telepíté- 
sét nem igényli a csatolt címtárakat futtató rendszereken. 


A szinkronizációs ciklus 

Az MA belső megvalósítást tekintve a címtár egy objektuma és 
egy szolgáltatás (service), mely a címtárszinkronizációt valósít- 
ja meg. Meghatározza, hogy a szinkronizációt hogyan kell elvé- 
gezni, és végre is hajtja azt. Az MA működésének három fázisát 
egy szkript írja le, ezek a felderítés (discovery), szinkronizáció, 
és a frissítés (update): 
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5 A Management Agent szinkronizációs fázisai 


A felderítési és a frissítési fázisok általában közös kódot használ- 
nak a csatolt címtár elérésére és a címtáradatok olvasására/írására. 
Az MA lelke a szinkronizációs fázis, mely import és export mintákat 
(template-eket, sablonokat) és attribútumáramlási szabályokat 
(melyeket az MA objektum tulajdonságaként tárol) használ a válto- 
zások jellegének megállapítására, mely alapján a metacímtár és a 
csatolt címtár frissíthető. 

Az MMS beépítetten tartalmazza a legelterjedtebb identitáskezelő 
rendszerekhez szükséges MA-kat (ügynököket), melyek a következők: 
"0 Active Directory Management Agent 

"0 Banyan Vines Management Agent 

"I Generic Management Agent 

"B Lotus cc:Mail Management Agent 

"8 Lotus Notes Management Agent 
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ha 


"8 LDAP alapú Exchange Management Agent 
"8 MAPI alapú Exchange Management Agent 
8 Microsoft Windows NT Management Agent 
"B Netscape LDAP Management Agent 

"8 — Novell Groupwise Management Agent 

"8 LDAP alapú Novell NDS Management Agent 

"I Novell Netware Management Agent 

"0 Report (jelentéskészítő) Management Agent 

"b TogetherrAdministration Management Agent 


A támogatott MA-k alapesetben a legtöbb, az adott gyártó címtá- 
rában gyakran használt attribútumot kezelik. A Lotus Notes MA pél- 
dául a Notes OfficeTelephoneNumber attribútumát az LDAP tele- 
phoneNumber attribútumára képezi le, illetve a Notes szervezeti 
felépítés alapján hozza létre a kezdeti hierarchiát. 

Az eredeti MA-k szkriptjeinek és sablonjainak módosításával a 
rendszer működése az egyedi implementációkhoz hangolható. Az 
Exchange például lehetőséget ad ún. Custom Attribute, azaz egye- 
di mezők használatára, melyekben tetszőleges, cégspecifikus infor- 
máció tárolható. Az MA-k szkriptje könnyen módosítható úgy, hogy 
a MA az Exchange Custom-Attribute-1 paraméterét specialTelepho- 
neNumber-re képezze le a metacímtárban. 

A Management Agent Toolkit-ben leírt információk alapján lehető- 
ség van új MA típusok készítésére is. Amennyiben egy rendszer (pl. 
egy adatbázis) képes adatokat fájlba exportálni, könnyen készíthe- 
tő olyan MA, mely e fájlt feldolgozza, és az adott adattár és a me- 
tacímtár tartalmát szinkronizálja. Adatbázisalapú, UNIX, VMS, 
05/400 vagy egyéb nem-Windows platformon futó alkalmazások 
ezzel a módszerrel könnyen integrálhatók a metacímtárba. 


Változó adatok kezelése 

Vajon ki tartja karban azokat az adatokat, melyek több címtárban is 
szerepelnek? Ha a metacímtárban is és másutt is változtatjuk az ada- 
tokat, azok fokozatosan kiesnek a szinkronból. Az MMS-ben megha- 
tározhatjuk, hogy objektumok mely címtárban hozhatók létre, hol tö- 
rölhetők, sőt azt is, hogy az egyes attribútumok 
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5 A Management Agent üzemmódjai 


Helyi (elosztott) menedzsment 

Az MA reflektormódú működése esetén a metadirectory egyszerűen 
követi a csatolt címtárban elvégzett törléseket és beszúrásokat. Az 
asszociációs mód gyakorlatilag a reflektor módnak egy esete, mely- 
ben a két címtárat megfeleltetjük ugyan egymásnak, de nem integ- 
ráljuk őket. Ez a mód általában átmeneti állapotot képvisel a ref- 
lektor mód felé, mivel lehetővé teszi az importálandó adatok átte- 
kintését, mielőtt azok a metaverzumba kerülnek. 


Központosított menedzsment 

Ha az MA kreátor módban működik, objektumokat csak a metacím- 
tárban lehet törölni vagy létrehozni, mely műveletek azután végre- 
hajtódnak a csatolt címtárakban is. Ha a csatolt címtár kiesik a 
szinkronból, a MA automatikusan helyrehozza a kapcsolatot, szük- 
ség szerint véve fel vagy törölve elemeket a csatolt címtárból. 


Attribútumok kezelése 

Az MA üzemmódja kizárólag az objektumok törlésének és létrehozá- 

sának helyét határozza meg. A létező objektumok attribútumai akár 

a metacímtárban, akár a csatolt címtárban módosíthatók, függetle- 
nül az MA üzemmódjától. Eltérő attribútumok 


hol változtathatók. Az MMS nem esetén az attribútumáramlási (attribute-flow) 
Az MA-k rendszeresen, időzítetten összehason- öz ük tl szabályok feladata a megőrzendő változat kivá- 
lítják az csatolt címtárak és a metacímtár tar- igényel semmilyen lasztása. Az attribútumáramlási szabályok al- 
talmát. Ha az adatok eltérnek, az MA szinkro- szoftverkomponens- kalmazásához azonban a metaobjektumot és a 
nizálja azokat. Az eltérések kétfélék lehetnek: telepítés t csatolt címtárobjektumot össze kell kötni (a 


valamely címtárban szerepelő objektum egy 
másikban még nem létezik, vagy egy mindkét 
címtárban szereplő objektum bizonyos attribútumai különböznek. 
Az MA ezeket az eltéréseket a benne megfogalmazott konfigurációs 
és szinkronizációs szabályok alapján oldja fel. 


Objektumok kezelése 

Az MA üzemmódja (operating mode) határozza meg, hogy a meta- 
címtár objektumainak létrehozása, illetve törlése hol végezhető - 
vagy a metacímtárban (centralizált menedzsment), vagy a csatolt 
címtárban (helyi vagy elosztott menedzsment). A működési módok 
a következők lehetnek (lásd a következő ábrán): 

Reflector (reflektor, követő): a csatolt címtárban elvégzett beszúrá- 
sok és törlések tükröződnek a névtérben és a metaverzumban. 
Creator (kreátor): a névtérben és a metaverzumban elvégzett törlé- 
sek és beszúrások tükröződnek a csatolt címtárban. 

Association (asszociáció, társítás): a csatolt címtárban elvégzett 
beszúrások és törlések tükröződnek a névtérben de nem görge- 
tődnek be a metaverzumba. 
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windows / 


megfelelő konnektortér-bejegyzés segítségével). 


Az illesztés (join) 

Az illesztés egy metaobjektum és egy adott, konnektortér-beli 
objektum között teremt kapcsolatot, ezáltal pedig közvetetten 
a metaobjektumot magához a csatolt címtárbeli objektumhoz 
kapcsolja. A kapcsolat létrehozható automatikusan, valamiféle 
szabály alapján, vagy interaktívan. 

Változatos illesztési lehetőségekre több okból is szükség van: ha bi- 
zonyos objektumok több csatolt címtárban is szerepelnek, de nem 
akarjuk őket egyetlen metaobjektummá egyesíteni, vagy ha nem 
dönthető el automatikusan, hogy egy adott metaobjektum illetve 
egy konnektortér-beli objektum azonos entitást képvisel-e. 

Az illesztést háromféleképp végezhetjük el: 

A Compass kliens Join Action funkciójával automatikus, kötegelt 
illesztés hozható létre valamilyen feltétel alapján, melyet aztán 
tetszőleges alkalommal lefuttathatunk. Általában a csatolt címtá- 
rak első betöltésekor használjuk. Az illesztési szabály által nem 
kezelt kivételek esetében nem konnektorok, hanem diszkonnek- 
torok keletkeznek, melyeket a különálló Account Joiner alkalma- 
zással oldhatunk fel, manuálisan választva ki egy létező metaob- 
jektumot vagy pedig létrehozva egy újat. Az időközben létrejövő, 
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új objektumok kezelésére az MA beállítható. 

Az illesztés automatikus elvégzéséhez fel kell állítani annak szabá- 
lyait (a join kritériumokat) . Erre a Configure the Join (illesztés beál- 
lítása) felület használható, melyet a Join Action és az MA join 
funkciója egyaránt tartalmaz. 
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5 Az illesztési szabályok beállítása 


A Join Action a konnektortér valamennyi diszkonnektorát meg- 
vizsgálja, a beállított szabályoknak megfelelő párt keresve hoz- 
zájuk a metaverzumban. A keresés eredményeként esetleg több 
lehetséges párosítás is adódik. A Join Action ezután a beszámí- 
tási (inclusion) szabályok alapján dönti el, hogy ezek közül me- 
lyeket tartsa meg. Ha adódik megfelelő illesztés, akkor a két be- 
jegyzés között létrejön a kapcsolat. 

A Try to join before reflecting new entries kapcsoló arra utasítja a 
reflektormódban működő MA-t, hogy az új bejegyzések létrehozá- 
sa előtt próbáljon illesztést keresni a már meglévő bejegyzésekkel. 
Az Account Joiner segítségével lehetőségünk van arra, hogy kü- 
lönböző szabályokkal kísérletezzünk, amíg egy megfelelően il- 
leszthető objektumot találunk, vagy újat hozunk létre. Az így ki- 
próbált szabályokat azután beépíthetjük az MA által használt 
automatizmusok folyamatába. 


Attribútumáramlási szabályok 

Ha egy metaobjektumot több MA is frissít, előfordulhat, hogy felülír- 

ják a másik által módosított attribútumokat. Ennek elkerülésére az 

MA-k attribútumáramlási szabályainak meg kell határozniuk, hogy az 

egyes attribútumoknak mely csatolt címtár a hiteles forrása. 
Metadirectory 


7 


Csatolt címtárak 


Konnektor 
Metaversum 
9 névtér 





Telefonszám ri Telefonrendszer 





j . B 
Telefonszám , Wii Bá 


1 Telefonszám , [ 
jú t Notes 


5 Attribútumáramlás a metacímtárban 


A fenti ábrán a telefonszámok hiteles forrása a telefonrendszer, az 
MMS-t tehát úgy állítjuk be, hogy a telefonszámok módosítását 
csak innen fogadja el. Az itt végzett módosítások eljutnak vala- 
mennyi rendszerbe, felülírva a Notes vagy az Exchange rendszerben 
(esetleg jogosulatlanul módosított) értékeket. 

Az attribútumáramlás ezen szabályai a következő ábrán látható fe- 
lületen adhatók meg: 
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5 Az attribútumáramlás beállítása 


A kérdéses attribútumot kiválasztva, és valamely irány-gombot 
megnyomva létrehozható egy egyszerű szabály a telefonrend- 
szer MA-jében. 

$mv.telephoneNumber - $cd.telephoneNumber 

Ez a szabály írja le azt, hogy a metaverzum telefonszám-attribútu- 
ma a telefonrendszer csatolt címtárában található telefonszámra 
állítandó. Az Exchange és Notes MA-jeiben a szabály ehhez hason- 
lít, de ellenkező irányú: 

$cd.telephoneNumber - $mv.telephoneNumber 

A fenti ábrán látható Advanced Flow Script lehetőséget ad 
összetettebb, szkriptjellegű szabályok megfogalmazására is. Az 
ellenőrzésnek e szintje adja a metacímtár elosztott jellegét le- 
hetőséget biztosítva arra, hogy az egyes attribútumokat abban 
a rendszerben tartsuk karban, ahol az a legkézenfekvőbb: glo- 
bális adatok (pl. alkalmazotti azonosítók) központilag, lokális 
adatok (pl. telefonszámok) helyben kezelhetők. 


Adat-transzformáció 

Az MA-k bizonyos feldolgozás után adatokat írnak vissza a csatolt 

címtárakba, az attribútumok egyszerű átadása azonban az alábbi 

gyakori esetekben nem elegendő: 

5 Ha valamely csatolt címtárbeli attribútumnak nincs pontos 
megfelelője a metacímtában. 

-0 A metacímtárban és a csatolt címtárban lévő adatok formátu- 

ma eltérő. 

A kapcsolat valamelyik oldalán az információ több mező össze- 

kapcsolásából áll csak össze. 

"2 Ha egy mező kiegészítésre szorul annak érdekében, hogy a 
metacímtárban az egyediséget fenntartsuk. 

"I Ha a csatolt címtár vagy a metacímtár olyan objektumot 
tartalmaz, melyet a kapcsolaton nem kívánunk átvinni. 

Az MA-k template-ek (minták, sablonok) alapján határozzák meg az 

attribútumok beolvasásának és frissítésének módját. A sablonokat 

egy magasszintű, interpretált nyelven fogalmazzuk meg, melyet az 

import program értelmez és az adatátvitel során felhasznál. 

Az MA templatenyelv az alábbi lehetőségeket tartalmazza: 

8 Egyszerű, közvetlen módosítások elvégzése. 

"0 Beépített függvények alkalmazása. 
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" Más metacímtár objektumok adatainak felhasz- 
nálása. 
"I  Utasítások feltételes végrehajtása. 
"b A címtár-frissítésekben érintett 
(bevont vagy kizárt) objektumok meghatározása. 
Az alábbi táblázat bal oldali oszlopa egy olyan rekordot mutat, me- 
lyet a cc:Mail Export/Import eszközével készítettünk a metacímtár 
importeljárások előkészítése során. Jobboldalt az a beolvasó sablon 
látható, mely az előző információt a csatolt címtár attribútumaival 
és ideiglenes változók segítségével írja le. 














File ege du ET 3 

Name: Dunn, Matt Name: $v. surname, $v. givenname 
Locn: L Locn: $cd.zeCclocation 
Addr: ccmPO Addr: $cd.zcCcPostOffice 
Cmts: Cmts: $cd.description 


Nyilvánvaló, hogy ez a csatolt címtár nem publikál sok attribútu- 
mot. Ennél sokkal több szükséges azonban egy metacímtár-bejegy- 
zés létrehozásához. Valamilyen értékekkel fel kell töltenünk például 
a bejegyzés Distinguished Name és object class paramétereit. Ezek 
a kiegészítő adatok a bejegyzésben szereplő identitásadatokból és 
a MA által tárolt egyéb információkból együttesen állíthatók elő. 
Ennek megvalósításához a beolvasó (parsing) sablonok kiegészíté- 
seként minden MA tartalmaz néhány konstrukciós sablont is. 
A példában szereplő konstrukciós sablonon szemléltetjük ennek 
működését: 
If $cd.zcCcLocation - P (ha ez Postafiók bejegy- 
zés) 
then 
$mv.zcoc - organizationallnit 
$cs.zcoc 5 


(object class) 


zcCcMailPostoffice, zcAliasThing, Top 
$mv.organizationalUnitName - 
$v. surname( , $v. givenName) 


else 
$mv.zcoc - zcPerson 
$cs.zcoc - zcCcMailBox,zcAliasThing, Top 
$mv . commonName - $get  substring( "$v. givenNamet 
(A $v.surname)", "", "e" 


endif 


A példa teljes mélységű megértése természetesen nem szüksé- 
ges, jól szemlélteti azonban, hogyan használható a sablon az 
információ átadására. 

Érthető, hogy a reflektor MA a konstrukciós sablont használja egy 
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új objektum létrehozása során. Mi a helyzet viszont akkor, ha a 
megfelelő metaverzum bejegyzés már létezik, és a konnektorhoz 
már illesztettük? Mi történik az attribútumáramlási szabályokkal? A 
válasz az, hogy a konstrukciós sablonok csak a beállítandó adatok 
értékét állítják elő, de nem feltétlenül jegyzik be azt - ez már az 
egyes MA-k attribútumáramlási szabályai alapján történik. 


A felvétel/távozás megvalósítása 

A metacímtár egyik legfontosabb szolgáltatása az egyes vállala- 
ti rendszerekhez való hozzáférés biztosítása az alkalmazotti cik- 
lus folyamán. Amikor az illetőt felveszik, szüksége lesz bizonyos 
erőforrásokra (pl. fájlok, nyomtatók), szolgáltatásokra (pl. e- 
mail) . Egy-egy előléptetés alkalmával ezen jogosultságok, szol- 
gáltatások módosulhatnak. 

Az MMS ezt a funkcionalitást a TAMA (Together Administration 
Management Agent) segítségével valósítja meg. A TAMA egy speciá- 
lis MA, mely más MA-k működését képes koordinálni, képes arra, 
hogy a csatolt névterekben konnektorokat, ezáltal pedig a csatolt 
címtárakban objektumokat hozzon létre. Ezt a működést általában 
egy új bejegyzés létrehozása váltja ki. A TAMA ezután más MA-kban 
konnektorokat hoz létre, melyek aztán a csatolt címtárak objektu- 
mait képviselik. Például egy új bejegyzés létrehozása a HR konnek- 
tortérben eredményezheti egy új Windows NT fiók, egy Exchange 
postafiók és egy Notes azonosító létrehozását. A TAMA az MA-k által 
alkalmazott szkriptnyelvet használja az új fiókok létrehozási módjá- 
nak pontos leírására. Hasonlóan, ha valaki távozik a cégtől (törlik a 
személyügyi alkalmazásból), a TAMA gondoskodhat a csatolt címtá- 
rakban hozzá tartozó accountok felszámolásáról vagy letiltásáról. 


Metadirectory Services és az Active Directory 

Az MMS 2.2 a következő szolgáltatásokkal egészíti ki az Active 

Directoryt: 

2 Több, egymással összekapcsolt címtár szinkronizációja 
csillagtopológia mentén. 

2 Egy objektum különböző képeinek automatikus egyesítése 
egyetlen, központi objektummá. Bár nem reális azt feltételezni, 
hogy egy szervezet valamennyi identitásadata 10099-ban egye- 
síthető, az MMS rugalmassága nagyban segíti ennek elérését. 

-£ Valamely címtárnak egy-egy attribútum hiteles forrásaként való 
kijelölése. 

0 Az üzleti folyamatok támogatása a felvétel/távozás folyamatok 
megvalósításával. 


A cikk az alábbi Microsoft műszaki tanulmány alapján készült: 
Microsoft Metadirectory Services Concepts and Architecture 
http://www.microsoft.com/windows2000/techinf. 
Ahowitworks/activediret MMSintro.a: 
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Április 1.-től az eddiginél jóval nehezebb helyzetbe kerülhetnek 
azok, akik az Internetet ártó szándékkal használják. Ha valami- 
lyen, a Büntető Törvénykönyvben meghatározott tényállást va- 
lósítanak meg, akkor adott esetben sokéves börtönbüntetéssel 
is számolhatnak. A korábban ismertek mellett új elkövetési alak- 
zatok is megjelentek a törvényben, ezzel korábban bűncselek- 
ménynek nem minősülő magatartások is e körbe kerültek. 

A magántitok védelme eddig is fontos célja volt a jogalkotásnak, és 
annak kifürkészése és rögzítése már alapesetben is öt évig terjedő 
szabadságvesztéssel volt büntethető. Lényeges hiányossága volt a- 
zonban a Büntető Törvénykönyvünknek (közismert rövidítéssel Btk.- 
nak) , hogy a jogvédelmet nem terjesztette ki sem a világhálóra, sem 
a belső hálózatokra. Ez történt meg a Btk. legutóbbi módosításával. 
Bűncselekményt tehát az követ el, aki a más részére hírközlő beren- 
dezés útján vagy számítástechnikai rendszeren másnak továbbított 
közleményt, adatot kifürkész, és az észlelteket technikai eszközzel 
rögzíti. A közlemény kifürkészésén kell érteni minden olyan maga- 
tartást melynek célja a közlemény tartalmának jogosulatlan megis- 
merése úgy, hogy másnak a titkát aprólékos gonddal felderíti. 

Az e-mail jogosulatlan elolvasása tehát önmagában még nem bűn- 
cselekmény, csupán szabálysértés. Ellenben ha annak tartalmát 
fájlba elmentjük, bizony hosszas hűsölésre számíthatunk a rácsok 
mögött. Aki azonban az e-mail tartal- 
mához úgy fér hozzá, hogy ehhez vala- 
milyen számítástechnikai rendszer vé- 
delmét biztosító intézkedést játszik ki, 
bűncselekmény elkövetőjévé válhat. 

Az Európa Tanács keretében előkészí- 
tett, és Budapesten, 2001. novemberé- 
ben elfogadott Informatikai bűnözés el- 
leni Egyezmény égisze alatt terjesztette 
ki a Btk. a bűncselekmények körét a 
hackerekre. Új tényállás került be a tör- 
vénybe a 300/C. § alatt számítástechni- 
kai rendszer és adatok elleni bűncselek- 
mény címen. A bűncselekmény elkövetője bárki lehet, aki a rendszer 
védelmét szolgáló intézkedés megsértésével vagy kijátszásával oda 
jogosulatlanul belép, vagy belépési jogosultsága kereteit túllépve, il- 
letőleg azt megsértve bent marad. Az e-mail jogosulatlan kifürkészé- 
se önmagában tehát nem biztos, hog bűncselekmény, ám aki más le- 
velezőrendszerébe jogosulatlanul behatol, még akkor is bűncselek- 
ményt követ el (és egy évig terjedő szabadságvesztéssel számolhat) , 
ha nem olvassa el az ott található üzeneteket. 

Felmerülhet a kérdés: vajon bűncselekményt követ-e el az a ked- 
ves munkatárs vagy netán főnök, aki távollétünkben leül a gé- 
pünk elé, és azt bekapcsolva szépen végigolvassa az e-mailjein- 
ket? Hiszen ez esetben szó sincs a védelmi intézkedés kijátszá- 
sáról. Jó hírem van azok számára, akiknek az elképzelés kapcsán 
már borzolódott a szőr a hátukon: igen, ez is bűncselekmény, bár 
csupán vétség, és így egy évig terjedő szabadságvesztés lehet a 
maximum, amit ezért kedves kollegánk kaphat. 

Az igazi hackerek azonban nem elégszenek meg azzal, hogy egy 
adott rendszerbe behatoljanak, ott ennek nyomát is akarják hagyni. 
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tudásával, ismereteivel 
segíti a hackert, ugyancsak 
bűncselekmény 
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évig terjedő 
szabadságvesztéssel 
számolhat. 
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Hiszen ügyességüknek, tudásuknak ez lenne fényes bizonyítéka. Nos, 
aki illetéktelen behatolás során a rendszerben valamilyen adatot jo- 
gosulatlanul megváltoztat, töröl, vagy hozzáférhetetlenné tesz, vagy 
akár a rendszer működését jogosulatlanul akadályozza, már két év 
hűsöléssel számolhat. Aki pedig mindezt nemcsak a saját ügyességé- 
nek tanúsítására, hanem bankszámlája hizlalásra is fel kívánja hasz- 
nálni, az okozott kár nagyságától függően akár tíz évet is kaphat. 
Az a szakértő, aki tudásával, ismereteivel segíti azt a hackert, aki ön- 
maga nem elég ügyes, vagy netán a számítástechnikai rendszerbe va- 
ló belépést lehetővé tevő kódot, jelszót elkészíti, esetleg megszerzi, 
vagy a feltörést biztosító kódot árusítja, ugyancsak bűncselekmény 
elkövetőjévé válik, és két évig terjedő szabadságvesztéssel számol- 
hat. (Mostantól nem tarthatunk security tanfolyamot? Az IPSec cikk 
szerzője már csomagolhat is, megy a dutyiba! — a szerk.) 

Az említett, Informatikai bűnözés elleni Egyezmény 9. Cikkében 
foglaltaknak megfelelően a Btk. a tiltott pornográf felvétel vagy 
felvételek vonatkozásában új elkövetési magatartásokat nyilvánít 
bűncselekménnyé. Az Egyezmény kiindulópontja a gyermekekről ké- 
szült pornográf felvételekkel kapcsolatos magatartások (készítés, 
megszerzés, átadás, tartás, forgalomba hozatal) átfogó, teljes tilal- 
ma. A törvény is ennek megfelelően rendeli büntetni az ilyen cse- 
lekményeket, és új elkövetési magatartásokat iktat be. 

Tiltott pornográf felvételek megszerzését 
és tartását három évig terjedő szabad- 
ságvesztéssel rendeli büntetni a törvény. 
Ezzel tehát a felhasználó is büntethető- 
vé vált, ha nem tesz mást, mint a világ- 
hálón található pedofil tartalmú oldala- 
kat letölti saját gépére és ott tárolja azo- 
kat. Súlyosabb minősítést von maga 
után egyetlen pornográf képfelvétel akár 
ingyenes, akár ellenszolgáltatás fejében 
meghatározott személy részére történő 
átadása, illetőleg kínálása is. Vagyis 
A törvény nem változtat a hatályos törvény által is büntetni ren- 
delt elkövetési magatartások miatt megállapítható büntetési téte- 
len: a tiltott pornográf felvétel készítését, forgalomba hozatalát, 
ilyen felvétellel történő kereskedelmet, valamit annak nagy nyil- 
vánosság számára hozzáférhetővé tételét továbbra is két évtől 
nyolc évig terjedő szabadságvesztéssel rendeli büntetni. 

Fontos megjegyezni, hogy bűncselekménynek csak a gyermek- 
pornográfiát tartalmazó felvételekkel kapcsolatos magatartások 
minősülnek. Az egyéb erotikus, vagy éppen pornóképek meg- 
szerzése, átadása, akár az azokkal való kereskedelem még akkor 
sem bűncselekmény, ha éppen durva,. hard pornóról van szó. 

A most ismertetetett rendelkezések csak a Btk. új, április 1.-től 
hatályos szabályai. Természetesen nem kerülhetett sor a teljesség 
igényével mindazoknak a cselekményeknek a bemutatására, ame- 
lyeket a Btk. bűncselekménnyé nyilvánít, és amelyeket jellemzően 
nagy számban éppen az Interneten lehet elkövetni. 


Dr. Mayer Erika 
mayer(onadas-mayer.hu 
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ámadás az 
IPSec ellen 


Amire az IPSEC csomagszűrőnél figyelni kell 


A tech.net magazin III. évfolyamának első számában olvashattuk, hogyan használható a 
Windows 2000 IPSec implementációja, mint egyszerű csomagszűrő. Sajnos ez a tulajdon- 
ság csak melléktermék, tervezéskor egyáltalán nem szerepelt a célok között. Ezt hallva az 

olvasó rögtön gyanút foghat, vajon nem származik-e ebből valami alapvető probléma. 


A gyanút fogott olvasónak igaza van, ugyanis az IPSec szűrők al- 
kalmazásánál vannak kivételek, vagyis egyes csomagokkal - még 
ha meg felelnek is a szűrőfeltételnek - nem foglalkozik az IPSec. 
A cikk további részében először ezeket a kivételeket sorolom fel, 
majd mutatok egy példát a csomagszűrésre mindössze abból a 
célból, hogy lehessen mit megkerülni. A példát IPSecpol pa- 
ranccsal építem fel, egy kis többletet adva az előző cikkhez. A 
példa után pedig belevágunk a legizgalmasabb részbe, vagyis ho- 
gyan élhetünk (vissza) a kivételekkel. Eközben néhány hasznos 
eszközt is megismerünk. Szerencsére, az utolsó részben kiderül, 
miként lehet mégis értelmet adni ,barkács" csomagszűrőnknek. 


A kivételek 

Az [1] URL-en található tudásbázis cikk alapján a következő há- 

lózati csomagok hatolnak át a szűrőn: 

"0 Broadcast: ha a csomag célcíme valamiféle broadcast cím, 
vagyis a csomagot több gépnek szánták. 

b Multicast: ha a csomag célcíme valamiféle multicast cím (a 
multicast címek tartománya a 224.0.0.0 -239.255.255.255). 

"0 RSVP (Resource Reservation Protocol): A 46-os számú IP 
protokoll, amit OoS (Ouality of Service) szolgáltatásoknál 
használ a Windows 2000. 

"0 IKE (Internet Key Exchange): Az IKE-t használja az IPSec, 
hogy biztonságosan cseréljék ki a felek a paramétereket (ha 
a szűrőfeltétel akcióparamétere megköveteli azt), és osztott 
titkosító kulcsot hozzanak létre. A lényeg, hogy a Windows 
2000 mindig UDP csomagokat használ az IKE forgalomhoz 
(500-as forrás és célcímmel). 

"0 Kerberos: ez a Windows 2000 alapvető authentikációs proto- 
kollja, amit az IKE is használhat IPSec authentikációra. Mivel 
a Kerberos eleve titkosított, nincs szükség arra, hogy IPSec- 
kel titkosítsuk. Csomagszűrőnknél ez úgy köszön vissza, hogy 
az minden olyan UDP és TCP csomagot átenged, aminek a for- 
rás- vagy célportja 88-as. 

A nagyobb gyakorlattal rendelkező olvasó már biztosan látja, 

hogy milyen súlyos problémával állunk szemben, de még mielőtt 

belemennénk, lássuk a megkerülendő példát. 


Példakonfiguráció 

Legyen a példakonfiguráció a lehető legegyszerűbb. A célunk 
az, hogy csak meghatározott gépek érhessék el az Internetre ki- 
rakott webszerverünket, aminek IP-címe 192.168.2.4. Legyenek 
e ,távoli" gépek mondjuk a következő IP-címekkel ellátva: 
192.168.2.1 és 192.168.2.2. Az ezt megvalósító IPSecpol [2] 
parancssorozat a következő: 
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IPSecpol -w REG -p "PacketFilter" -r "HTTPin" 
$ -f 192.158.2.2r192.158.2.4:80:TCP 

4 -f 192.158.2.16192.158.2.4:4U3:TCP 

W -f 192.158.2.2r192.158.2.4:80:TCP 

GW -rf 192.258.2.2r192.25b8.2.4:4U3:TCP -n PASS 
IPSecpol -w REG -p "PacketFilter" -r "DenyAll" 
GW -f "r192.1b8.2.4 -n BLOCK 

IPSecpol -w REG -p "PacketFilter" -x 


Az így kreált politikát pedig a következő paranccsal törölhetjük: 
IPSecpol -o -w REG -p "PacketFilter" 


Lássuk a paraméterek jelentését: 

2 -w Típus: Tartomány. Az IPSecpol parancsnak kétféle műkö- 
désmódja van: dinamikus és statikus. Dinamikus módban a 
megadott parancsok csak a , IPSec Policy Agent" szolgálta- 
tás leállásig maradnak érvényben. Statikus esetben a gép 
újraindításával sem veszik el a beállítás. Ez utóbbit érjük el 
a -w paraméterrel. A Típus változónak két értéke lehet: REG, 
ami a regisztrációs adatbázisban való eltárolást jelent vagy 
DS, ami az AD-ban tárolja az általunk megadott politikát. Az 
utóbbi esetben a Tartomány változón keresztül megadhat- 
juk, melyik tartományról van szó. . 

2 -p Név: a politika neve, amire a parancs vonatkozik. Ha még 
nem létezik ilyen néven, a parancs létrehozza azt. 

0 -r Név: a hozzáadandó szabály neve. Ha már létezik, akkor a 
parancsnak megfelelően módosul. 

6 -f A.B.C.D/mask:port-A.B.C.D/mask:port:protocol. Itt adjuk 
meg a szűrőfeltételt, vagyis azt, hogy a szabály milyen cso- 
magokra vonatkozik. Mint a példában látható, egy szabály- 
hoz több szűrőfeltétel is tartozhat. A szűrő két részből áll, 
amit vagy egy -- vagy egy - jel választ el egymástól. Ha -- je- 
let használunk, akkor lényegében két szűrő jön létre, vagyis 
a megadott feltétel érvényes lesz mindkét irányban. A két 
rész a forrás és cél beállításait tartalmazza. Az IP-cím helyén 
megadhatunk fix IP-címet vagy egy IP-címtartományt alhá- 
lózati maszkkal együtt. A " jellel bármely IP-cím előfordulá- 
sát megengedjük, a 0-val saját IP-címünkre hivatkozhatunk, 
és megadhatunk DNS nevet is. A cél- és forrásport megadá- 
sának helye elég egyértelmű a példából, de akár el is hagy- 
ható, hasonlóan a protokollmezőhöz, ami a szűrőfeltétel leg- 
végén szerepel. Lehetséges értékei ICMP, UDP, RAW ,TCP. 

"B -n PASS vagy BLOCK: itt definiáljuk a szabályhoz tartozó ak- 
ciót (esetünkbenben PASS), ami engedi a szűrőfeltételeknek 
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megfelelő csomagot. Lehetne BLOCK is, ami megakadályoz- 
ná a csomagok átjutását. 

b -x vagy -y: Akárcsak a GUI-t (Graphical User Interface, az 
egerészős változat) használó változatnál, itt is hozzá kell 
rendelni a politikát a géphez (ha a helyi regisztrációs adat- 
bázisba mentettük), csak azután lép működésbe a szűrőnk. 
Erre való az -x kapcsoló. A hozzárendelés megszüntetéséhez 
az -y kapcsolót használhatjuk. 

0 -o: Segítségével törölhetjük a létrehozott politikát. 

Láthatjuk, hogy milyen egyszerűen hozható létre parancssorosan a 

csomagszűrő. A fenti példából könnyedén gyárthatunk parancsállo- 

mányt, aminek segítségével rugalmasan konfigurálhatjuk gépün- 
ket. Az IPSecpol maga is támogatja ezt a -file paraméterrel, ami 
után megadott állományból a parancs végrehajtja az utasításokat. 

Miért járjuk ezt az utat? Talán azért, mert vannak, akik jobban 

szeretik a parancssoros, mint a GUI eszközöket. Azt se felejtsük 

el, hogy nagyon jó, ha rendelkezésünkre áll az IPSec politikát 
létrehozó parancsállományunk: bármikor és bármelyik gépen 
előállíthatjuk a kívánatos állapotot. Akkor is hasznos lehet, ha 
csak ideiglenesen akarjuk felvenni a kapcsolatot egy másik gép- 
pel IPSec-en keresztül, és ezért nem akarjuk megváltoztatni az 

AD-ben tárolt beállításainkat. Még egy fontos dologra szeretném 

felhívni a figyelmet: nem teljesen ugyanúgy 

viselkedik az IPSecpol parancs, mintha a 

GUI-t használtunk volna. A különbségekről 

a [3] címen lehet bővebben olvasni. 


Megkerülés 

Az alábbi teszteket a VMWare [4] szoftver segítségével végeztem, ami 
azt jelenti, hogy három operációs rendszer futott egyszerre a tesztgé- 
pen. Az áldozat egy alap Windows 2000 Server volt, a támadó operá- 
ciós rendszereken pedig a Windows 2000 Professional futott. 

Mi a rosszszándékú támadó első lépése? A támadható rendsze- 
rek, szolgáltatások felderítése. Mi is ezzel kezdjük. Megnézzük, 
hogyan lehet portszkennelő eszközzel a szűrőt megkerülni (a 
portok végigpróbálgatásával szolgáltatást keresve a célrendsze- 
ren). Erre a célra szerintem legjobb program az nmap, ami le- 
tölthető az [5] címről. A program eredetileg Unixos világra ké- 
szült, de a forrást letöltve könnyedén lefordítható Windows 
platformon is (a forrásfában megtalálható a Visual C4-- projekt- 
állomány) . Az nmap rengeteg paraméterrel rendelkezik, ezért itt 
csak a példához szükségeseket adjuk meg. A megkerüléshez azt 
a tulajdonságot használjuk ki, hogy megadható, milyen forrás- 
portról folyjék a portok végigpróbálgatása. 


nmap -sS -PO 192.158.2.4 
nmap -sS -g 88 1972.15b8.2.4 


Az első parancs futása az adott környezetben 1096 másodpercig 
tartott, aminek örülhetünk, hiszen sikerült jelentősen lelassíta- 
ni a támadót (a kezdőknek ez gyakran elveszi a kedvét), IPSec 
nélkül mindössze 6 másodpercig tartott ugyanez. Sajnos a ka- 
pott eredmény már nem ilyen szép: 

Port State Service 


88/tcp closed kerberos-sec 

Hogy mért nem, ahhoz először tekintsük át az nmap működését. 

A használt paraméterek jelentése a következő: 

"8 -s[S, U, X...]: A szkennelés típusát adja meg, ami többek 
között lehet UDP, Xmass, FIN, NULL, de akár végig is pin- 
gelhetünk egy címtartományt (erről részletesebben szintén 
az [5] címen lehet olvasni) . Amit esetünkben használunk, az 
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a SYN szkennelés. A TCP portokat próbálja végig, 
méghozzá úgy, hogy a háromlépcsős TCP kapcso- 
lat felépítésből csak az első két lépcsőt valósítja 
meg. Elküldi a SYN csomagot, és a visszajövő 
SYN/ACK-ra ACK helyett RST-vel válaszol. (Akinek ez kí- 
naiul van, annak javaslom a tech.net 2001/III. számában a 
NetMon cikk elolvasását: a TCP csatornát elemzi.) Mivel a TCP 
kapcsolat nem épül ki, alkalmazásszinten nem történik be- 
jegyzés a naplókba a kísérletről. Ezért is szokták ezt a módot 
vstealth", rejtőzködő szkennelésnek nevezni. Nyilván a portot 
csak akkor jelenti nyitottnak, ha SYN/ACK-ot kap válaszul. 
"8 -PO: Az nmap a szkennelés előtt megpróbálja megállapítani, 
hogy az adott IP-címek élnek-e. Egyszerűen megpingeli 
(nem csak ICMP-n keresztül) őket. Ha ez nem volt sikeres, 
akkor bele sem kezd a munkába. Ez a tulajdonság kapcsol- 
ható ki a -PO-val. Nagyon sok tűzfal úgy van beállítva, hogy 
az nmap kezdeti próbálgatásai sikertelenek maradnak. Ilyen 
a mi IPSec szűrőnk is. 
Azért látom problémásnak az első eredményt, mert ha egy por- 
ton nem fut szolgáltatás, akkor a protokoll szerint a kapcsola- 
tot kezdeményező gépnek RST/ACK választ küld vissza a célgép. 
Már az előző cikkben is szerepelt, hogy az IPSec egyik előnyös 
tulajdonsága, hogy nem küld semmiféle 
választ a sikertelen próbálkozásokra, de 
amint láthatjuk, az első port-szken- 
nelésünk eredményéből (a kivételként 
kezelt Kerberos protokoll miatt) a 88-as 
portról visszakaptuk az RST/ACK-t. A 
port ugyan zárva van, de erről értesítést kaptunk (RST). Ez baj. 
Ebből már gyaníthatja is a támadónk, hogy itt egy IPSec-kel vé- 
dett Windows 2000-ről van szó. Ekkor próbálkozik a második 
nmap utasítással, ahol a -g paraméter hatására a program min- 
den kérést 88-as portról indít. Úgy teszünk tehát, mintha 
Kerberossal kopogtatnánk - pedig dehogy! Így a kapott ered- 
mény a következő lesz: 


C:WWINNTYsystem322nmap -sS -g 88 172.15b8.2.4 


Starting nmap V. 2.SUBETAZ2A (www.insecure.org/nmap 
) 

Interesting ports on (1972.158.e.4): 

(The 1532 ports scanned but not shown below are in 
state: closed) 


Port State Service 
7/tcp open echo 

9g/tcp open discard 
13/tcp open daytime 
17/tcp open gotd 

19/tcp open chargen 
21/tcp open ftp 

25/tcp open smtp 

42/tcp open nameserver 
53/tcp open domain 
80/tcp open http 
135/tcp open loc-srv 
139/tcp open netbios-ssn 
443/tcp open https 
445/tcp open microsoft-ds 
1025/tcp open listen 
2031/tcp open iad2 
3389/tcp open msrdp 

Nmap run completed -- 1 IP address (1 host up) 


scanned in 5 seconds 


eDB8. 85. 
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Olyasmire van szükségünk, 
amivel elérhetjük, hogy az 


88-as portról induljon ki. 


Ebből látható mekkora lyukat okozott a csomagszű- 

rőben, hogy az IPSec kivételként kezeli a Kerberos 

protokollt. Most lássuk, hogyan lehet ezt mélyebben 
kihasználni. 


IIS 


Olyasmire van szükségünk, amivel elérhetjük, hogy az általunk ki- 
küldött összes csomag a 88-as portról induljon ki. Ezt legkönnyeb- 
ben egy port-átirányító programmal tehetjük meg. Két programról 
érdemes itt beszélni. Az egyik a [6] címről letölthető fpipe, a má- 
sik a [7] címről letölthető winrelay. (Mindkét oldalon érdemes több 
időt is eltölteni.) A továbbiakban az fpipe-on keresztül mutatjuk a 
példákat. Lássuk az elsőt: 


fpipe -v -i 172.158.2.3 -1 80 -r 80 -s 88 
1792.248.2.4 


A -v paraméter hatására a program bőbeszédűen ecseteli, hogy 
éppen mit tesz. Az -i határozza meg, hogy melyik interfészen, az -l, 
hogy melyik porton 
hallgatózzon. Az -r 
után megadott port- 
ra továbbítja a cso- 
magokat az -s-sel 
megadott  forrás- 
portról. Az utolsó 
paraméter pedig a 
cél IP-cím. Vagyis a 
fenti parancs hatására, ha a 192.168.2.3-as IP-címre kapcsoló- 
dunk a 80-as porton, akkor minden, amit elküldünk átirányítódik 
a 192.168.2.4-es IP-cím 80-as portjára, és a csomagok forrásport- 
ja 88-as lesz. Így a támadó már szabadon elérheti a rendszerre ins- 
tallált webszervert. Windows esetében elég nagy az esélye, hogy 
ez IIS lesz, de támadónk óvatos, úgyhogy leellenőrzi. Ez megtehe- 
tő egy egyszerű telnettel is, de van erre sokkal alkalmasabb esz- 
köz: a Netcat. Szintén a Unixos világból érkezett, de Windowson 
is remekül működik. A [8] címről tölthető le. Gazdag funkcionali- 
tásából most csak ennyit használunk: 


általunk kiküldött 
összes csomag a 


C: WWINNTYsystem322nce -p 88 172.25b8.2.4 80 
HEAD / HTTP/1.0 


HTTP/1.2 200 OK 

Server: Microsoft-IIS/5.0D 

Date: Sun, 24 Mar 2002 07:15:08 GMT 

Connection: Keep-Alive 

Content-Length: 2270 

Content-Type: text/html 

Set-Cookie: 
ASPSESSIONIDGAGGAWZO-KECNIMMCNCIKIGAHHLIAEANF ; 

path-/ 
Cache-control: private 


(A figyelmes olvasó észrevehette, hogy nem használjuk ki a fen- 
tebb indított portátirányítást. A Netcat -p paraméterével megad- 
ható, milyen forrásportról induljon a kapcsolat.) A támadó meg- 
nyugodhat, IIS fut a célrendszeren. Gondolom mindenki előtt 
világos, hogy ha a tesztrendszerünk gazdája, megnyugodva az 
IPSec nyújtotta védelemben, nem frissíti rendszerét, a támadó- 
nak nyert ügye van. 


wvörkindgd with 
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NetBios 

A fenti módszerrel a Windows rendszerek achilles-sarkán, a 
NetBios-on keresztül is támadhatunk. Itt van szükség a harma- 
dik gépre (192.168.2.5), mert így sokkal egyszerűbb a NetBios 
forgalmat a célrendszer felé irányítani. A közbülső gépen a kö- 
vetkező beállítást kell megtenni: 
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Advanced TCP/IP Settings 





IP Settings ] DNS. WINS ] Options ] 


7 WINS addresses, in order of use: 

! 

] a 
! 

! 

! 

! 


Edd 


a 


Add... Edit ] Remove 
IF LMHOSTS lookup is enabled, it applies to all connections for which 


TCPAP is enabled. 
Import LMHOSTS.. 


F Enable LMHOSTS lookup 


nable NetBIOS over TCPAP 
[sable NetBIOS over TCP/IP 
Use NetBIOS setting from the DHCP server 








5 A 139-es port így már nem foglalt 


Így a portátirányító program már képes kapcsolatkéréseket fo- 
gadni a 139-es porton: 


fpipe -v -i 192.1b8.2.5 -1 139 -r 139 -s 88 
$192.158.2.4 


Innen már indulhat is lerágott csontként a NetBios-on keresz- 
tüli enumeráció (a hírhedt ,, null session"). Számos eszköz léte- 
zik, Dunát lehet velük rekeszteni. Itt én három enumerációs, és 
egy támadóeszközt említenék meg, melyeket belső, betörési 
tesztjeim során előszeretettel alkalmazok. Az első a Languard 
Network Scanner [9], ami gyönyörű grafikus felületen tálalja 
elénk a megszerzett információkat. Véleményem szerint a leg- 
könnyebben használható eszköz, és minden információt meg- 
szerez, amit lehetséges. Sajnos esetünkben nem használható: a 
tesztek során nem volt képes együttműködni a portátirányító 
eszközzel. (Az okokat itt most nem részletezném, csak annyit, 
hogy a probléma gyökere az, hogy a portátirányítás miatt egy for- 
rásportról továbbítódik minden kérés.) A második egy sima pa- 
rancssori eszköz (az enum), és a [10] címről tölthető le. 


C: WWINNTYsystem322enum -U -M -S -P -G -L 
$192.158.2.5 
server: 1792.1b8.2.5 
setting up session... success. 
password policy: 

min length: none 

min age: none 


max age: none 





0: ús. 


lockout threshold: none 
lockout duration: 71582788 mins 
lockout reset: 30 mins 

opening 1lsa policy... success. 


server role: 3 [primary (unknown)] 


A paraméterek jelentését megkaphatjuk, ha nem adunk meg 
semmit, így egyszerű, de világos segítséget ad a használatáról. 
Azért kedvelem, mert lekérdezhető vele a rendszer kizárási poli- 
tikája. Mint fentebb látható, a támadó örülhet, mert a rendszer 
nem zárja ki a felhasználót sokszori sikertelen bejelentkezés 
után, így nyugodtan indíthat nyers erő (brute force) támadást a 
jelszavak ellen (ami szintén megtehető az enummal.) A harma- 
dik eszköz, melyet előszeretettel használok, a GetAcct [11], 
ami rendkívül hasznos nagy felhasználói számnál, ráadásul a 
RestrictAnonymous-1 beállítás sem jelent számára akadályt. 


CÍ Getácct ő lol2d 


Hemote Computer And of RID 


hs2.168.2.4 hoso 








sazzzssmzze ása] 
ESISSES esszmtj] 








Ddays Oh On Os Guest 
ldays 2h 272 295 Guest ] 


501 (cuezt Built-in ac 
1000 TsInternetU TelnternetU This user a 
1001 (IUSR ISS 


1002 IUAM ISS 


Internet CuBuilt-án acBuilc-in ac49days 13h 46m ZSz Guest 
Launch IIS Builc-in acBuilt-in ac49dayr 12h 46m 485 Gussr 
1007 (a a 


Zidays 15h 19m 65 Admánástrator 











5 A GetAcct működés közben 


A GetAcct eszköz a felhasználónevek begyűjtésére való. Azért 
kedveltem meg belső betörési tesztjeim során, mert le lehet 
menteni a kimenetét csv típusú szöveges állományba. Ez egy- 
szerűen beolvasható Excelbe, és ott különböző szempontok sze- 
rint rendezhető (pl. a , Priv" és utána a , Password Age" oszlop 
alapján), megkönnyítve a könnyen támadható felhasználók ki- 
választását. A képen látható, hogy a legsebezhetőbb felhaszná- 
lónak a ,g" tűnik. Valószínűleg tesztelési célokra használták, és 
ottfelejtették, ráadásul , Administrator" a privilégiuma. Feltéte- 
lezhető, hogy könnyen kitalálható jelszava van. Itt jön az utol- 
só NetBios eszköz, mely a pstools csomag része [12]. Számom- 
ra meglepő módon nem szokták hackereszközként említeni. Ta- 
lán azért, mert használatához Administrator jogokkal kell ren- 
delkezni a megtámadott gépen (de ez vonatkozik a többi távoli 
menedzsment eszközre is, amit ilyenkor szóba hoznak, pl. VNC 
[13], radmin [14]). A szóbanforgó eszköz, a psexec, melynek 
segítségével bármit lefuttathatunk egy távoli rendszeren: 


D:Ypsexec W172.358.2.5 -u g -p g cmd.exe 


PsExec v1.22 - execute processes remotely 
Copyright (C) 2002 Mark Russinovich 
Wwww.sysinternals.com 


Microsoft Windows 2000 [Version 5.00.2175] 
(C) Copyright 1985-1999 Microsoft Corp. 
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windows 7 


C: WWINNTYSsystem322cd N 
Cs 


Látható, hogy sikerült cmd.exe-t elindítani, mivel a g felhasz- 
náló jelszava megegyezett nevével. Olyan ez, mintha ,betel- 
neteltünk" volna: a ,cd W parancs már a szerveren futott. A 
psexec paraméterezése egyszerűen megérthető a példából, így 
külön nem térek ki rá, inkább továbblépek egy másik sebezhető 
szolgáltatásra. 


SNMP 

A hálózat-rendszergazdák kedvenc protokollja a Simple Network 
Management Protokoll. Segítségével statisztikát gyűjtenek, há- 
lózati térképet készítenek, ellenőrzik a rendszerek állapotát. A 
protokoll UDP alapú, és a 161-es porton fogadja a kéréseket. 
(162-es porton az snmptrap szolgáltatás fut, mely az SNMP ügy- 
nökök által generált üzeneteket, riasztásokat fogadja.) Három ok 
miatt foglalkozom vele. Először, mert segítségével megmutatha- 
tó, hogy a portátirányító módszer UDP protokollnál is működik 
(lásd Kerberos-kivétel). Másodszor, példaként szolgálhat arra, 
hogy miért veszélyes az, hogy a broadcast csomagokat sem szű- 
ri meg az IPSec. Harmadszor, számos hasznos információ van az 
SNMP szolgáltatás adatbázisában - ami lényegében egy faszer- 
kezet - melyet egy támadó felhasználhat. Az 


snmputil walk 192.25b8.2.3 public 
$.iso.org.dod.internet.private.enterprises. 
$ lanmanager 


utasítás hatására megkapjuk az SNMP-t futtató Windows rend- 
szerekről a felhasználólistát, a futó szolgáltatásokat és a 
megosztásokat. Az snmputil a Resource Kit része. A fenti utasí- 
tásban a 192.168.2.3-as IP-címet kérdezzük. A walkkal jelezzük, 
hogy az utolsó paraméterként megadott részfát szeretnénk be- 
járni. A public az installálás utáni úgynevezett community név. 
Ez az SNMP , jelszava". Szóval nemcsak a , NULL Session"-ön ke- 
resztül szerezhetünk hasznos információkat... 

Az fpipe használata most már egyértelmű kell, hogy legyen: 


fpipe -v -i 192.1b8.2.3 -1 1bl -r 1bl -u -s 88 
4192.15b8.2.4 


Egyetlen új paraméter tűnt fel az -u. Arra utasítja a programot, 
hogy UDP módban működjön. Ezzel az utasítással lehet eredmé- 
nyes az előző snmputil parancs. 

A broadcastproblémát a következő utasítással lehet szemléltet- 
ni, mely az snmpset paranccsal SET, azaz írási műveletet küld a 
192.168.2.255 címre - vagyis a teljes subnetre (azon belül per- 
sze a támadott gépre is): 


snmpset 172.158.2.255 private 
$.iso.org.dod.internet .mgmt . mib-2 
$.sysName.D s testl3 

Timeout: No Response from 172.25b8.2.255 


A portátirányításra itt nincs szükség, a broadcast bejut a szű- 
rőn. Mint látható, választ nem kaptunk, hiszen a forrásport most 
nem 88-as volt, így a válaszcsomagot, melynek a célportja nem 
88-as, nem engedte át az IPSec. Viszont ha lekérdezzük az adott 
értéket a MIB-ből (Management Information Base, így hívják az 
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SNMP faszerkezetű adatbázisát), akkor a , sssName" 
már a mi beállításunkat fogja tartalmazni. A táma- 
dás azért volt sikeres, mert az UDP nem kapcsolat- 
orientált protokoll, így elég volt, hogy a parancs elér- 
te a célrendszert, a válasz már nem fontos. A használt esz- 
köz az ucd-snmp [15] csomag része, ami szintén a Unixos vi- 
lágból származik, de mint látjuk használható Windows platfor- 
mon is. Paraméterezése hasonló az snmputil parancséhoz, de itt 
meg kell adni a változó típusát (az , s" azt jelenti, hogy string 
típusú) és az értékét is. Azért használtuk ezt, mert az snmputil 
nem támogatja az SNMP set parancsát. (Az igazat megvallva sok 
kárt nem okoztunk ezzel a rendszeren, de a veszélyt remélem si- 
került vele érzékeltetni.) Még hozzátenném, hogy Windows 
2000-en a telepítés utáni állapotban az SNMP szolgáltatásnál 
külön kell engedélyezni, hogy távolról írni lehessen a MIB-et. 


Nincs minden veszve 
Szerencsére az SP1 telepítése után lehetőségünk van beállítani a 
következő DWORD típusú változót a regisztrációs adatbázisban: 


HKEY. LOCAL MACHINENSYSTEMNCurrentControlSetv 
WServicesulPSec WobefaultExempt 


Ha a NoDefaultExempt értéke 1, akkor az IPSec nem kezeli kivé- 
telként a Kerberos és az RSVP protokollokat, elhárítva ezzel a 
legnagyobb veszélyt, de így is megmarad a broadcastcsomagok 
kivételként kezelése. 


Összefoglalás 

Tanulság: jóllehet teljesen biztosak vagyunk a gép védelmében, 
mégse hanyagoljuk el az alapvető biztonsági intézkedéseket, 
(mint például a fölösleges szolgáltatások tiltását, a már nem hasz- 
nált felhasználók törlését, az erős jelszavak használatának kény- 
szerítését és a biztonsági javítások telepítését. ) 

A célom nemcsak az volt e cikk írása közben, hogy felhívjam a 
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figyelmet az IPSec szűrő problémáira, hanem szerettem volna 
érzékeltetni, milyen módszerek és eszközök állnak a ,rosszoldal" 
rendelkezésére. Írásom a terjedelmi korlátok miatt nem töreked- 
het a teljességre, de remélem sikerült növelnem a cikket olvasó 
rendszergazdák paranoiaszintjét. 

És végül, ha rákényszerülünk az IPSec csomagszűrő használatá- 
ra, ne felejtsük el beállítani a fentebb említett kulcsot! 


Tóth László 
laszlo.toth okpmg.hu 
KPMG Hungária KFT. 
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DumpSec ( 


NTFS jogosultság listázása 


Több alkalommal is felmerült a NetAcademia listáin a kérdés, vajon hogyan lehetne 
megállapítani, hogy egy felhasználónak milyen tényleges jogai vannak egy könyvtár- 
ban, illetve milyen eszközzel lehetne akár egy egész könyvtárstruktúra aktuális hozzá- 
férési szabályairól kimutatást készíteni. Nos, egy beépített eszköz és egy szabadon 
használható szoftver megoldást jelenthet a problémával küzdőknek. 


Röviden a mappa- és állományhozzáférésről 
Kevesen tudják, hogy a Microsoft új funkciót épített be a Win- 
dows XP-be a fájlhozzáférések ellenőrzésére. A funkció neve , ha- 
tályos jogok ellenőrzése", és arra a kérdésre válaszol, hogy pon- 
tosan milyen jogai vannak egy felhasználónak egy adott map- 
pában vagy állományon. 
Miért? Lehet ez egyáltalán kérdés? Csak meg kell nézni a jogo- 
kat és kész. Aki így gondolkodik, az bizony nem tudja, hogyan 
kell a mappák hozzáférését szabályozni. Dióhéjban a három 
alapszabály a következő: 
1. Tegyük a felhasználókat globális csoportokba! 
2. Készítsünk , Domain local" csoportokat, majd a megfelelő 
mappában rendeljünk melléjük hozzáférési engedélyeket! 
3. Helyezzük el a globális csoportokat a , Domain local" 
csoportokba! 
Miért ilyen bonyolult ez? Nos, ha az elnevezéseket megváltoztatjuk, 
mindjárt kiderül, hogy a valósághoz egész jól idomul ez a modell. 
Használjuk a ,globális" név helyett a , szervezet", ,projekt" vagy 
nteam" szót (pl.: informatika, számvitel, kereskedelmi igazgatóság 
stb.)! Amikor egy felhasználót egy ilyen csoportban elhelyezünk, 
nem teszünk mást, mint vállalatunk szervezeti hierarchiáját csopor- 
tokra képezzük le. 
Most gondoljuk végig, hogy hányféle jogot adunk egy mappán! 
Háromfélét: olvasási jogot a vezetőknek, írási jogot néhány beosz- 
tottnak és teljes jogot a rendszergazdáknak. 
Ha létrehozunk három lokális csoportot, akkor 
mindegyikbe beledobhatjuk a megfelelő szer- 
vezetet reprezentáló globális csoportot. Így 
elértük, hogy minimális bejegyzés legyen a 
jogosultságlistában, és állandó maradhasson 
a lista, továbbá, hogy más tartományokban 
létrehozott csoportoknak is ugyanúgy adhas- 
sunk jogokat, hiszen a lokális csoportok más 
tartománybeli globális csoportokat is tartalmazhatnak. Ha felve- 
szünk egy új munkatársat, elegendő betenni a fiókját a megfelelő 
szervezetet vagy teamet reprezentáló listába, máris engedélye van 
több tucat könyvtárhoz, nem kell átnyálazni minden alkalommal 
az összes mappa listáját. 
A megoldás persze hordoz hátrányokat is, például nehéz megálla- 
pítani, hogy miért nincs egy felhasználónak valamihez joga, ami- 
kor kellene, hogy legyen. Ezt a problémát oldja meg az effektív jo- 
gokat megjelenítő panel a Windows XP-ben. 
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Hatályos jogok ellenőrzése Windows XP-vel 

Ha egy mappa biztonsági beállításainál XP alatt a Speciális gomb- 
ra kattintunk, a Windows 2000-hez képest bővebb panellel talál- 
kozunk. Történetünk szempontjából a legutolsó fül az érdekes. Ide 
kattintva az alábbi ábrát láthatjuk: 


Alu - speciális biztonsági beállítások 
Engedélyek / Naplózás ! Tuzjdonos ( Hatályos engedélyek ) 


Az alábbi ata azokat 


élyeket mutatja, amelyeket a kijelöl csoport vagy felhasználó az összes 
alkölmazható engedély megkap. 


] 
E szg] 
] 
Hatályos engedélyek. 
B Tekes hozzáférés 
18 bejárása. fáj végrehagása 
EZ Mappa istázása. adatok olvasása I 
EZ] Aürbútunok olvasása I 
) EZ ktegesztett atttbútumok olvasása 
D fájok létrehozása. adatok írása 
! ED Maggák létrehozása. adatok hozzálűzése 
) ED Atrbútumok írása 
( ED ktenesztett attibútumok írása 
D Aimappák és lájok tötése 
1 B Tövés 
EZ Engedélyek olvasása 
) D Engadétrek módos tása 
CD Saját tulajdonba vétel 


5 A pontos engedélyek egy felhasználó esetében 


Akármilyen sok csoportunk van is, és akármilyen bonyolult is a map- 
parendszer, amelyben a jogosultságokat ki kell értékelni, a Windows 
XP pillanatok alatt elvégzi a kiértékelést. Meg 
kell adni a felhasználó vagy csoport nevét, és 
máris minden hatályos jog kiderül. 

Egyetlen felhasználó esetén ez egészen jól 
használható funkció. A teljes jogosultságlista 
dokumentálására a Systemtools cég birtokába 
került, de még a Somarsoft által fejlesztett 
DumpSec nevű ingyenes eszköz alkalmas. 


Egy sokoldalú apró program 

A DumpSec leánykori neve DumpAcl, és a Systemtools weblapján 
az áll, hogy már nem fejlesztik tovább. Kár, mert nagyon hasznos 
kis segédprogram. Eredetileg a fájlrendszer jogosultságlistáinak 
kinyerésére készítették, de aztán egyre bővült a jelentések sora. 
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Dumo Permezarz fer Prnterz ! 
Dino Pomzzorz for Sharez 

Dump Permsízos fer Shared Drectery.. I 
mo Permasora fer AJ Sharcd Örertones Í 


Dumo users az con. 
Dino User az table. 
Duo Groxoz az czkamn 


0 A DumpSec puritán felülete és legfontosabb funkciói 


Ma már nemcsak a fájlrendszer, hanem a regisztrációs adatbá- 
zis, a megosztások és a nyomtatók jogosultságai is listázhatók 
mind helyi, mind távoli gépről. Adatokat kaphatunk továbbá a 
szolgáltatásokról, az NT4-es értelemben vett házirendről, de 
még a felhasználói jogokról is. 

A program használatát nagyon gyorsan el lehet sajátítani. Min- 
denekelőtt ki kell választani a célszámítógépet, amelyről a je- 
lentést el akarjuk készíteni (Report/Select Computer... ). Ezután 
be kell állítanunk, hogy milyen listát szeretnénk (Report/ 
Permission Report Options... ). 


(akát ae za 


(7 . Show only dírectoriez and (les whose permissions dílfer 
írom thase of parent directory fexception dís and fdes) 
(this is the most useful report) 

" C Show dírectories (but not files) whose perméssions differ 
! rom those of parent dírectoty (exception dís, no fides) 


(this report ís produced the fastest) 
-C Show all dírectories, pluz files whose permissions díífer 
. —— hromthose of patent díreciory (all dírz, exception fides) 
€ Shaw all dítectories but no fdes (all díz, na files) 


Show all dírectories and files (all dírr and files) 


5 A leghasznosabb listát az első gombóccal készíthetjük 


Ötféle lehetőségünk van. A legegyszerűbb, ha csak a kivételeket je- 
lenítjük meg. Ekkor egy mappa vagy állomány tartalmának jogosult- 
sága csak akkor jelenik meg, ha az eltér a szülőmappáétól. Azért ez 
a leghasznosabb jelentési forma, mert az almappák és állományok 
nagyon nagy része a szülőmappától örökli a jogosultságokat, tehát 
elég a szülőt ismerni, a gyerek úgyis a szülőre ütött. Ha egy map- 
pát vagy állományt áthelyeztünk valahonnan, akkor a jogosultsága 
eltér a mostani szülőjétől: ez az, ami minket leginkább érdekel. 
Persze az is lehet, hogy csak a kivételes mappákkal akarunk fog- 
lalkozni (második gombóc) , vagy minden mappával és csak a kivé- 
teles állományokkal (harmadik gombóc), a többi értelemszerű. 
Beállíthatjuk továbbá, hogy jelölje-e a tulajdonosokat a lista, il- 
letve, hogy a naplózási információk megjelenjenek-e. Egy bizton- 
sági audit esetén nagyon hasznos lehet az utóbbi lehetőség. 
Miután beállítottuk a lista paramétereit, nincs más dolgunk, mint 
kiválasztani az elemezésre kiszemelt mappát. Ha az egy távoli 
szerveren található, sajnos előbb csatlakoztatnunk kell, mint há- 
lózati meghajtót, de ezt tekintsük szépséghibának. Az elkészült 
listát rögtön elemezhetjük, de el is menthetjük ötféle formátum- 
ban, melyek közül az egyik a DumpSec sajátja. 

A fájlok és könyvtárak biztonsági tulajdonságainak megjelenítése 
mellett az alkalmazás egyéb listázási tulajdonságai sem elhanya- 
golhatók. Különös figyelmet érdemel a felhasználók listázása. Igaz, 
a DumpSec még az NTA világot ismeri, az Active Directoryt is csak 
úgy látja, mintha egy NT4 címtár lenne. Ez azonban nem kevés le- 
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hetőséget nyújt a rendszergazdáknak. Minden korábbi tulajdonság 
tetszőleges sorrendben listázható, sőt, még egy speciális jelenléti 
ívet is készíthetünk. A DumpSec minden egyes tartományvezérlővel 
képes felvenni a kapcsolatot azért, hogy megállapíthassa, tényle- 
gesen melyik felhasználó mikor lépett be utoljára. Több telephely 
esetén ez jelentős hálózati forgalommal járhat, ezért inkább csak 
kevésbé forgalmas időszakokban javaslom ilyen lista készítését. 


MAs At 


1 Show computer account: 
IZ. Show"ue" last logon time (e. search all logon servers) 


5 Katalógus: Ki nem dolgozik mostanában? 


Hab a tortán 

A segédprogram készítői a rendszergazdák fejével gondolkodtak, 
amikor nemcsak a grafikus felületet alkották meg, hanem azt is biz- 
tosították, hogy minden funkció elérhető legyen parancssorból is. 
Két kötelező paramétere van a programnak: a riport típusa és a 
kimenetet tartalmazó állomány neve. Minden más opcionális. A 
szintaxis tehát ez: 


DumpSec.exe /rpt-£report type? [/optionszkvalue2 
/optionszfvalue2...] /outfile-doutput file name? 


A riport típusa tizenhatféle lehet, a kimenet formátumát pedig a 
/Ssaveaszcformat: kapcsolóval állíthatjuk olyanra, amilyen nekünk 
a legkedvesebb. 

Tizennégy nem kötelező kapcsoló finomíthatja az elkészítendő lis- 
ta formáját és tartalmát. Egy konkrét példa: 


DumpSec.exe /computer:scMVfilesrvODl 
/rptssharezjelentesek /showalldirs /noowner" 
/savesaszcsv /outfilezc:Vadmilogstusers.csv 


Az alkalmazás csatlakozik a filesrvOl szerverhez, majd a 
Jelentesek" megosztás minden könyvtárának jogosultságairól ké- 
szít egy listát úgy, hogy az nem tartalmazza a tulajdonosokat, az 
eredményt pedig csv formátumban egy megadott állományba men- 
ti. Ezt a parancsot már csak időzíteni kell, máris kész a havi jelen- 
tés a hozzáférési szabályokról. 

Nincs most alkalom és mód bemutatni minden egyes kapcsolót - 
szerencsére nem is kell. A DumSecet nagyon jó súgóval látták el, 
amely nemcsak a parancssori lehetőségeket taglalja, hanem rész- 
letes magyarázatot nyújt az elkészített riportok jelöléseiről, a vár- 
ható teljesítményről, de még az ismert hibákról is. 

Akinek felkeltettem az érdeklődését, az látogassa meg a követke- 


ző címet: http://www.systemtools.com/somarsoft/ 


Sok sikert a jelentések elkészítéséhez! 


Lepenye Tamás, MCSE 2000 
lepenyetomal.hu 
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Az XML Schema (II. rész) 


Az előző részben láthattuk, hogyan kell közvetlen egymásba ágyazással, referenciákkal és 
típusok definiálásával egyszerűbb sémákat szerkeszteni. Részletesen megnéztük hogyan 
lehet egyszerű típusokat létrehozni a már meglévő típusokból. Ebben a részben a komp- 
lex típusokat tekintjük át. Megnézzük, hogy összetettebb típusok létrehozására milyen 


fejlettebb nyelvi elemek állnak rendelkezésre. 


Összetett típusok 
A korábbi példákban a complexType sémaelemet mindig egy-egy 
elem deklarációján belül használtuk fel, mint például: 


£Xxsd:element name-"konyv"2 
£xsd:complexType2 
£Xxsd:seguence2 
Xxsd:element name-"cim" type-"xsd:Sstring"/2 


Ebben az esetben összetett típusunknak nincs neve, ezért nem 
is használható fel másutt, csak a konyv elemen belül. Az ilyen 
típusdeklarációt anonymousnak hívjuk. Ennek hátránya, hogy 
nem lehet újra és újra felhasználni, azaz csak azon a helyen 
hasznos, ahol definiáltuk. 

A típusdeklarációkat a schema elem alá is kiemelhetjük. Ha nevet 
is adunk nekik, bármely elem definiálásánál felhasználhatjuk őket: 


€1!-- konyvsema3.xsd --2 


£1-- Az egyszerű típusok deklarációja --2 

£€xsd:simpleType namez"nevTipus"2 
€xsd:restriction base-"xsd:string"2 

£Xxsd:maxLength value-z"32" /5 

£/xsd:restriction2 

£€/xsd:simpleType2 

£Xxsd:simpleType namez"szuletettTipus"2 
£xsd:restriction base-"xsd:date"/2 

£/xsd:simpleType2 

£Xxsd:simpleType name-" jellemzesTtipus"2 
£xsd:restriction basez"xsd:string"/2 

£/xsd:simpleType2 


€X1!-- Az összetett típusok definíciója --2 
£Xxsd:complexType name-"szereploTipus"2 
£xsd:seguence2 
Xxsd:element name-"nev" type-"nevTipus"/2 
Xcxsd:element name-"baratja" type-"nevTipus"/2 
€xsd:element name-"szuletett" 
type-"szuletettTipus"/2 
£Xxsd:element name-" jellemzes" 
type-" jellemzesTipus"/2 
€/xsd:seguence2 


£/xsd:complexType2 


£Xxsd:complexType name-"konyvTipus"2 


£xsd:seguence2 
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£XKxsd:element name-"cim" type-"nevTipus"/2 
X€xsd:element name-"szerzo" type-"nevTipus"/2 
Xxsd:element name-"szereplo" 
type-"szereploTipus"/2 
£/xsd:seguence? 
XKxsd:attribute name-"isbn" type-"isbnTipus" 
usez"reguired"/2 


£/xsd:complexType2 
£Xxsd:element name-"book" type-"konyvTipus"/2 


A példában két összetett típust (a szereploTipust és a konyvTipust) 
deklaráltuk. Látható, hogy a típusokba foglalt elemek hivatkozhat- 
nak további típusokra, így alakul ki a tervezett elemhierarchia. 

A típusok a kiemeléssel és megnevezéssel újrahasznosíthatóvá 
váltak. Nyilvánvaló, hogy ha egy megnevezett típust bármely 
elem típusaként felhasználhatunk, ezzel munkát spórolunk meg 
a séma megírása és karbantartása során. Hamarosan kiderül, 
hogy ennél jóval többet is tudnak a kiemelt és elnevezett ele- 
mek. Ehhez azonban még át kell tekintenünk néhány fogalmat. 


Tartalomtípusok 

Mi lehet egy elem tartalma? 

-? Lehet üres, azaz nincs se gyermekeleme, se közvetlen tartalma. 
2 Csak gyermekelemei vannak. 

2 Csak szöveges tartalma van. 

"2? Gyermekelemek és szöveges tartalom vegyesen található benne. 
Emellett még mind a négy esetben attribútumokat is tartalmaz- 
hat az adott elem. Hogyan lehet e különböző tartalmakat cso- 
portosítani és formálisan leírni? 

Az eddigi példákban már láttuk, hogyan kell olyan összetett tí- 
pusokat létrehozni, amelyek csak gyermekelemeket és/vagy att- 
ribútumokat tartalmaztak, ilyen volt például a konyvTipus. 
Tisztán tartalmat hordozott például a cim elem. Hogyan lehet 
olyan típust definiálni, amely közvetlen tartalmat hordoz, és 
vannak attribútumai is? Ehhez be kell vetnünk egy új sémaele- 
met, a simpleContentet: 


£1-- konyvsema4.xsd részlet--2 
£Xxsd:complexType name-"osszetettNevTipus"2 
£Xxsd:simpleContent2 
£xsd:extension base-"nevTipus"2 
£Kxsd:attribute name-"nem" 
£/xsd:attribute2 


type-"xsd:string"2 


£/xsd:extension2 
£/xsd:simpleContent2 
£/xsd:complexType2 
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Azért egyszerű tartalom (simpleContent), mert a 
komplex típusunknak nincsenek gyermekelemei, csak 
közvetlen szöveges tartalma és attribútumai. 
Az xsd:extension a simpleContenten belül azt jelzi, hogy 
a base attribútumban megadott egyszerű típust (simple type) 
vagy egyszerű tartalmat hordozó összetett típust leszármaztatás 
segítségével egészítjük ki. Ez azt jelenti, hogy az így előállt egy- 
szerű tartalmú összetett típusunk minden jellemzőjében a 
nevTipussal lesz azonos, csak kiegészítjük egy , nem" nevű attribú- 
tummal. Ha a nevTipusnak lennének attribútumai, akkor azokat au- 
tomatikusan örökölné az osszetettNevTipus összetett típusunk. 
Próbáljuk ki mire jutottunk! Ha megnézzük az előző (konyvse- 
ma3.xsd) forrást, akkor láthatjuk, hogy a szereplő neve egy 
nevTipus típussal van leírva. Ez-nem enged meg semmilyen att- 
ribútumot a névben, így a következő részlet nem érvényes az 
eredeti séma alapján: 


€XKnev nem-"fiú"2Snoopyk/nev2 

Ha azonban a sémában a 

£€xsd:element name-z"nev" type-"nevTipus"/2 
sort kicseréljük az alábbira: 


€Xxsd:element name-"nev" 
types"osszetettNevTipus" /2 


akkor mindjárt elfogadja a ,nem" attribútumot is. Ebből látszik, hogy 
működik ugyan az új attribútum deklarációja, de még nem látszik 
a leszármaztatás hatása. Ezt is könnyen ellenőrizhetjük, hisz a 
nevTipusunk maximum 32 karakter hosszú neveket engedett meg, így 
ha működik az öröklés, akkor ez igaz lesz az osszetettNevTipusra is. 


Xnev 


Validation Error: The element has an invalid 


value according to its data type. 


nev 


Remek, megy a leszármaztatás, a 32 karakternél hosszabb szö- 
vegeket az osszetettNevTipus sem fogadja el. 

Most tehát egy egyszerű típusból származtattuk le az egyszerű 
tartalmat hordozó összetett típusunkat. Ha kell egy olyan típus, 
ami mindenben azonos az osszetettNevTipussal, csak még kell 
hozzá egy plusz attribútum, akkor egyszerűen le kell származtat- 
nunk, és ki kell egészítenünk az új típust a plusz attribútummal. 
Például lehet mindenkinek megszólítása: 


£Xxnev2 nem-"fiú" megszolitasz"Mr."?2Snoopyk/neve2 
Egy ilyen elemet a következő komplex típus ír le: 
£1-- konyvsema5.xsd részlet --2 
£xsd:complexType name-"mrNevTipus"2 
£xsd:simpleContent2 
£xsd:extension base-"osszetettNevTipus"2 
£Xxsd:attribute name-"megszolitas" 
type-"xsd:string"? 
£/xsd:attribute2 
£/xsd:extension2 
£/xsd:simpleContent2 
£/xsd:complexType2 
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Ebben a példában egy egyszerű tartalmat hordozó összetett tí- 
pusból örököltünk. 

Azaz (egyszerű vagy összetett típusból örököltetve) most már att- 
ribútummal, és anélkül is létre tudunk hozni egyszerű tartalom- 
mal rendelkező elemeket. 

Ha egy összetett típusban vegyesen, gyermekelemeket és köz- 
vetlen tartalmat is szeretnénk használni, akkor ezt a mixed att- 
ribútum segítségével jelezhetjük. Például ahhoz, hogy a szerep- 
loTipusnak lehessen tartalma is a gyermekelemeken felül: 


Kszereplo2Itt ugyan semmi értelme 
£Xxnev nem-z"fiú"2Snoopyk/nev2 
szövegnek, de miért ne? 


Az ezt megengedő komplex típus deklarációja a mixed attribú- 
tummal jelzi szándékunkat: 


£1-- konyvsemab.xsd részlet --2 
€Xxsd:complexType name-"szereploTipus" 
mixed-"true"? 


A gyermekelemek között megbújó szöveges tartalom még abból 
az időből lehet ismerős, amikor az xml elődjét, az SGML-t, szö- 
vegek kiegészítésére használták (pl. a HTML-ben is ezt tesszük). 
A mai világban, amikor az xml-t főleg információk átvitelére 
használjuk, a mixed modell használata nem nagyon elterjedt. Az 
információt attribútumok és egyszerű tartalommal rendelkező 
gyermekelemek hordozzák. 

Hogyan lehet üres elemet definiálni? Egyszerűen nem írunk 
gyermekelem-definíciókat a complexType belsejébe, és nem en- 
gedjük meg a mixed modellt sem. 

Már csak egy dolog maradt hátra. Ha van simpleContent, akkor 
várhatóan lesz complexContent is. Ezzel hozhatunk létre leszár- 
maztatott összetett tartalmat (gyermekelemeket, attribútumo- 
kat, esetleg közvetlen tartalmat) hordozó típusokat. 

Például minden szereplőről le szeretnénk írni annak korát is (il- 
lékony adat, de miért ne?): 


$£kor213£/kor2 
£€/szereplo2 


Mivel már van egy összetett típusunk a szereplők leírására, kár 
lenne veszni hagyni, inkább származtassunk abból egy újabb tí- 
pust, és egészítsük ki egy ,kor" elemmel: 


€X!-- konyvsema?.xsd részlet --2 
£Kxsd:complexType name-"bovitettSzereploTipus"2 
£Xxsd:complexContent2 
£Xxsd:extension base-"szereploTipus"2 
£xsd:seguence2 
£Xxsd:element name-"kor" type-"xsd:int" /2 
£/xsd:seguence2 
£/xsd:extension2 
£/xsd:complexContent2 
£/xsd:complexType2 


Ha belegondolunk, ez a klasszikus, 00OP-s értelemben vett örök- 
lés. A sématípusok nagyon hasonlóak a programozott típusok- 
hoz, például C$ (C---) nyelven így nézne ki (egyszerűsítve) a 
szereploTipus és a bovitettSzereploTipus: 
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class szereploTipus ( 
string nev; 
string neve; 
string baratja; 
datetime szuletett; 
string jellemzes; 
§ 
class bovitettSzereploTipus: szereploTipus ( 
int kor; 


A séma típusszármaztatási lehetősége jól kihasználható lenne az 
xml séma és a programozott osztályok közötti átjárást biztosító 
sémafordítókban (schema compilers, .NET-ben a wsdl.exe), azon- 
ban ezek az eszközök jelen pillanatban nem nagyon élnek ezzel a 
lehetőséggel. Mi magunk viszont egyszerűen használhatjuk őket. 
Nem túl bonyolult, a névterek bevezetése után azonban eléggé 
kacifántos tud lenni. Egyesek úgy érvelnek, hogy ne használjuk a 
séma öröklési lehetőségeit. Viszont a típusok újrafelhasználásra 
szükségünk van, és erre van is lehetőségünk: a csoportosítás. 


Csoportosítások 

Gyakori, hogy több elemet vagy attribútumot több összetett tí- 
pusban is fel szeretnénk használni. Összeszedhetjük őket egy- 
egy alaptípusba, és leszármaztatással bárhol felhasználhatjuk 
őket. Másfelől össze tudjuk terelni őket egy-egy csoportba, és 
típusainkból a csoportokra hivatkozhatunk! 


£1!-- konyvsema8.xsd részlet --2 
£X!-- elemcsoport létrehozása --2 


£xsd:group name-r"konyvFoElemek"2 
£Xxsd:seguence2 
£Xxsd:element name-"cim" typesz"nevTipus"/2 
£Xxsd:element name-"szerzo" typez"nevTipus"/2 
£/xsd:seguence2 
£/xsd:group2 


£X!-- attribútumcsoport létrehozása --2 


Xxsd:attributeGroup name-"konyvAttributumok"2 
XKxsd:attribute name-"isbn" type-"isbnTipus" 
use-z"reguired"/5 
£xsd:attribute name-"rendelheto" 
types"xsd:string"/2 
£€/xsd:attributeGroup2? 


A group sémaelemen belül hasonló tartalmat láthatunk, mint 
amit az összetett típusok deklarálásánál elemeztünk. Az attribú- 
tumok összefogására külön sémaelem van, az attributeGroup. 
Mivel az attribútumok sorrendje (definíció szerint) érdektelen, 
ebben az esetben nem kell a seguence vagy bármely más sorren- 
det és/vagy számosságot befolyásoló compositor. 

Az elkészült csoportokra (hivatalos nevük Model Group) hason- 
lóan hivatkozhatunk, mint az egyedi elemekre és attribútumok- 
ra: a ref attribútumon keresztül. Lássuk a csoportokat alkalma- 
zó konyvTipust: 


£Xxsd:complexType name-"konyvTipus"2 
£xsd:seguence2 
£xsd:group ref-"konyvFoElemek" /2 
£Xxsd:element name-"szereplo" ... /2 
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£/xsd:seguence2 
£Kxsd:attributeGroup 
ref-"konyvAttributumok" /2 
€/xsd:complexType2 


Pont olyan, mint az előző számban látott globális elem- és att- 
ribútumhivatkozás ref-fel, csak itt csoportokra hivatkozunk. 

A Compositorok közül eddig csak a seguence compositort láttuk, 
ami azt írja elő, hogy a benne felsorolt particle-öknek a 
megadott sorrendben kell szerepelni a példánydokumentumok- 
ban. A particle elemek, elemcsoportok és a bármilyen elemet 
reprezentáló any elemek összessége. A célnévtérbe elemeket ge- 
nerálni képes séma komponenseket összefoglalóan particle-ök- 
nek hívjuk (szép magyar szó!). 

További két compositor is van, a choice és az all. A choice, aho- 
gyan a neve is utal rá, a benne definiált elemek vagy elemcso- 
portok között biztosít választási lehetőséget. Például hozzunk 
létre egy olyan csoportot, amely egy ember nevét ábrázoló ele- 
meket tartalmaz. A szabály legyen az, hogy vagy meg kell adni 
az ember teljes nevét egyben, vagy szétbontva családi és ke- 
reszt-, valamint egy opcionális második keresztnévre: 


£Xxsd:group name-z"nevek"? 
£xsd:choice? 
£xsd:element namez"nev" type-"xsd:String" /2 
£xsd:seguence2 
Xxsd:element name-"csaladinev" 
type-"xsd:String" /2 
€xsd:element name-"keresztnev" 
type-"xsd:string" /2 
£xsd:element name-"masodikKkeresztnev" 
types-"xsd:string" min0Occursz"O" /5 
£/xsd:seguence?2 
£/xsd:choice? 
£/xsd:group? 


Látható, hogy a choice-on belül nemcsak egyszerűen elemeket 
vagy csoporthivatkozásokat, hanem minden további nélkül to- 
vábbi compositorokat is használhatunk. 

Az all compositor azt jelenti, hogy a benne felsorolt elemek (és 
semmi más, még csoport sem) bármilyen sorrendben szerepelhet- 
nek a példánydokumentumban. Például a konyvTipus esetén nem 
biztos, hogy cim, szerzo és szereplo elemek sorrendje fontos. Ed- 
dig ott seguence compositor volt, cseréljük azt ki all-ra. Ebből 
problémáink származnak, mert szereplo elemekből több mint egy 
is megengedett, viszont az egyértelműség miatt az all composi- 
tor ezt nem engedi meg: minden elem maxOccurs értéke (kardi- 
nalitása, számossága) legfeljebb 1 lehet. Emiatt azt gondolnánk, 
hogy csak a cim és a szerzo elemek lesznek az all-ban, a szerep- 
lo elemdeklarációt pedig belerakjuk egy seguence-be. Azonban 
egy összetett típuson belül nem lehet csak egy compositor, azaz 
vagy all, vagy seguence. Mit lehet tenni? Sajnos ezt a feladvány 
nem lehet megoldani az all compositorral, azaz le kell nyelnünk, 
hogy meg lesz kötve az adatok sorrendje, marad a seguence. 
Ennek ellenére számos helyen jól bevethető az all compositor. 
Például gyakori, hogy adatbázistáblák tartalmát generáltatjuk le 
xml-ként. A táblák sorait egy-egy elem reprezentálja: 


£cuccok2 
IKtablalkxkoszlopl/2Xoszlop2/2S/tablab 
XKtablalk2kKoszlope/2Xoszlopl/2£/tablal2 
£/cuccok2 
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Ilyenkor a feldolgozás szempontjából általában tel- 

jesen érdektelen a táblák oszlopait ábrázoló elemek 

sorrendje, ezért például a következő séma írhatja le 
az adatokat: 


€xsd:element name-"cuccok"2 
£Xxsd:complexType2 
£Xxsd:seguence maxOccurs-"unbounded"2 
€xsd:element name-"tablal" 
type-"tablalTipus" /2 
£/xsd:seguence2 
£/xsd:complexType2 
£€/xsd:element2 
£Xxsd:complexType name-"tablalTipus"2 
£xsd:all? 
€cxsd:element name-z"oszlopl" /2 
XKxsd:element name-"oszlope" /2 
£/xsd:all? 
£X/xsd:complexType2 


Megszorítások 

Gyakran logikai kapcsolat van az xml dokumentum által szállí- 
tott információk között. Ezen kapcsolatokat, és az adatokban 
rejlő szabályszerűségeket általában constraintek, megszorítások 
írják elő a különböző adattároló és szállító rendszerekben. Köz- 
ismert például, hogy az adatbázistáblákban (relációkban) a so- 
rok, azaz a modellezett entitiáspéldányok egyediségét az elsőd- 
leges kulcs hivatott ellenőrizni, , megszorítani". Ha a táblák kö- 
zött logikai kapcsolat van, akkor az idegen kulcsok lehetséges 
értékeinek szerepelnie kell a kapcsolódó tábla elsődleges kulcs- 
halmazában (tartomány épségi szabály). 

Egy xml dokumentumban gyakran többféle információtartalmat 
találunk. Az adatok között a sémadokumentumban definiálha- 
tunk kötöttségeket. A sémakötöttségek gyakorlatilag megegyez- 
nek az adatbázisokban megszokott megszorításokkal, hisz a gya- 
korlatban a legtöbb xml dokumentum forrása egy-egy adatbázis. 
Az egyik leggyakoribb feladat az egyediség biztosítása valamely 
elem vagy attribútum értékkészletén. Erre való a unigue sémaelem: 





£X!-- konyvsemal0.xsd részlet - 
€xsd:element namez"konyv" typez"konyvTipus"2 
£€xsd:unigue name-"EgyediSzereploNev"2 
€xsd:selector xpath-"szereplo" /2 
£€xsd:field xpathz"nev" /2 
£/xsd:unigue2 
£/xsd:element?2 


A selector elem xpath attribútumában megadott XPath kifejezés 
jelöli ki azt az elemet, amelyen értelmezni kell a field elem xpath 
attribútumában megadott érték egyediségét. Adatbázis-hason- 
lattal élve a selector választja ki a táblát, a field az egyedi érté- 
keket tartalmazó oszlopot. A példánkban nem lehet két azonos 
nevű szereplő ugyanabban a könyvben. De különböző könyvek- 
ben minden további nélkül lehetnek azonos nevű szereplőink. 
Hasonló módon szeretnénk biztosítani a könyvek isbn számai- 
nak egyediségét. Ehhez egy kicsit átalakítjuk a korábbi példán- 
kat, hogy több könyvet is tudjon tárolni, és megadjuk, hogy az 
isbn attribútum egyedi legyen: 


Xxsd:element name-"konyvek"2 
£xsd:complexType2 
£xsd:seguence maxOccursz"unbounded"2 
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£Xxsd:element name-"konyv" type-"konyvTipus"2 
£x1-- Az előző szereplőnév megszorítás --2 
£/xsd:element2 
£/xsd:seguence?2 
£/xsd:complexType2 
£Xxsd:unigue name-"EgyediISBN"2 
£xsd:selector xpath-"konyv" /2 
£Kxsd:field xpath-"eisbn" /2 
£€/xsd:unigue2 
€/xsd:element2 


Elég valószínű, hogy az isbn attribútumot a könyvek egyedi azo- 
nosítására használjuk, erre a célra azonban nem a unigue elem 
az igazi, mert az megengedi azt is, hogy az egyedi érték (field) 
ne szerepeljen a céldokumentumban. Adatbázis-hasonlattal él- 
ve: megengedi a null (xml-ben nil) értéket is. 

Valódi elsődleges kulcs jellegű adatok megkötésére inkább hasz- 
náljuk a key sémaelemet. Ez egy olyan unigue megkötés, ami 
nem engedi meg a null értékeket. A használata teljesen azonos 
a unigue-éval. 

Egymástól függő adatok esetén hasznos lehet idegen kulcsok 
definiálása. Erre a keyref sémaelem használható, mellyel hivat- 
kozást (referenciát) hozhatunk létre egy key-jel vagy unigue-kal 
azonosított kulcsra. Például kössük meg, hogy egy szereplő ba- 
rátja csakis a könyvben definiált szereplők közül kerülhet ki. 


£1-- konyvsemall.xsd részlet --2 
£€xsd:keyref refer-"EgyediSzereploNev" 
name-"FKSzereplő2 
€xsd:selector xpath-"szereplo" /2 
€Xxsd:field xpathz"baratja" /2 
£/xsd:keyref2 


Példánkban a keyrefet is a konyv elem belsejébe kell helyezni, 
azonban legtöbbször a hierarchia különböző pontjai között 
szoktunk hivatkozásokat definiálni. 

Láthatjuk, hogy ezeknek a funkcióknak semmi közük a korábbi részek- 
ben tárgyalt struktúradefiniáló elemekhez. Azok olyan típusok leírá- 
sára valók, amelyeket sokszor programozott típusok (class-ok) és xml 
dokumentumok közötti átjárásra használunk. Nem nehéz kitalálni, 
hogy a fő motiválóerő a Webszolgáltatás technológia háttértámoga- 
tása volt. Ezzel szemben a megszorítások, kulcsok egyértelműen ada- 
tok értékeinek megregulázására alkalmasak, ez pedig adatok átvite- 
le, üzleti adatok cseréje közben lehet hasznos. De a kettőt lehet öt- 
vözni is, mert például egy .NET-es Webszolgáltatásban egy paramé- 
terként átadott típusos DataSet táblái között lehetnek kapcsolatok, 
és ezt a DataSet key-keyref elemekkel modellezi le. A táblák adatai 
xml-ként mennek át, és az adatok épségét a kapcsolatok is elősegítik. 


Zárszó 

Szinte megismertük a séma összes elemét, így a következő záró 
részben áttekintjük a gyakorlati felhasználás részleteit COM és 
.NET világban is. 


Soczó Zsolt 
Zsolt.Soczo onetacademia.net 
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aszfaltozási munkálata 


A tech.net magazin februári és márciusi számában XMLgessünk címen Soczó Zsolt bemutat- 
ta az ADO.NET adatbáziskezelésének központi elemét, a DataSet objektumot. Egy 
memóriában tárolt adatbázis óriási kincs, de csak akkor, ha stabil technológiai kapoccsal 
összeköthető a meglévő adatbázisszerverekkel és a helyi gépeken tárolt XML állományokkal. 
Az alábbi cikk a két kapcsolódási felület közül az elsőt elemzi, és az SOLServer adatbázis és 
a DataSet objektum közötti híd , aszfaltozási munkálataiba" avatja be az Olvasót. 


Mielőtt az aszfaltozógépeket ráengednénk a hídra, vizsgáljuk meg a 
híd vázszerkezetét és a két pillért. Az adathíd alapszerkezetét az 
SalDataAdapter objektum alkotja. Az egyik pillér egy SOLServer 
adatbázis, a másik pedig egy DataSet objektumhoz tartozó 
DataTable objektum. A híd lehet egyirányú és egysávos, ha csak ar- 
ra használjuk, hogy az SOLServer adatbázisból feltöltsük a DataTable 
objektumot. Az SglDataAdapterrel kétirányú - és ezzel akár 1--3 sá- 
vos - híd is kialakítható, ha a DataTable-ben bekövetkezett válto- 
zásokat vissza akarjuk vinni az eredeti SOLServer adatbázisba. 


Adatok kiolvasása, azaz a híd első sávjának felépítése 

A híd egyik irányának felépítéséhez az SglIDataAdapter objektum 
SelectCommand tulajdonságadatát kell feltölteni az adatok 
visszanyerését szolgáló SgiCommand objektummal. 


Dim conSzamla As New SglConnection( 
W "user idssa;passwordzhaliho;" 8. 
"database-Szamla;data source-Gepl") 
Dim cmdPartner As New SglCommand( 
Wo "Select t From Partner Where PaTipus-zl", 
WconSzamla) 
Dim daPartner As New SglDataAdapter 
Dim dsPartSzla As New DataSet 
daPartner.SelectCommand - cmdPartner 


Ezzel tehát a híd az SOLServer adatbázisból a DataSet irányába 
már járható, így átjuttathatók rajta az adatok a Fill() metódus 
meghívásával. 


daPartner.Fill(dsPartSzla, "Szallito") 


A fenti metódushívás a daPartner nevű SglDataAdapter objek- 
tumnak a SelectCommand tulajdonságadatába betöltött SglCom- 
mand parancsát fogja felhasználni a dsPartSzla objektum feltöl- 
téséhez. A tényleges adatáttöltés elkezdése előtt az adott 
SgliCommand parancsban definiált adatbáziskapcsolatot 
(conSzamla) megnyitja a rendszer, majd az SOL parancs által 
visszaadott adatszerkezeti információk alapján felépít egy 
DataTable objektumot "Szallito" néven. A DataTable objektum 
neve (TableName tulajdonságadat) - ahogy a példában is látha- 
tó - nem szükségképpen egyezik meg az adatbázisbeli táblanév- 
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vel. Az adatszerkezet kialakítása után az adatbázisból érkező 
adatsorokkal (a PaTipus-1 feltételnek eleget tevő partnerek adatai- 
val, azaz mondjuk a szállítókkal) feltölti a dsPartSzla-hoz tartozó 
sSzallito" nevű DataTable tartalmát. A , feltöltés" tulajdonképpen 
nem más, mint annyi DataRow objektum létrehozása és DataTable 
objektumhoz történő hozzákapcsolása, ahány eredménysort a 
fenti SOL parancs visszaadott. Az adatfeltöltést követően a rend- 
szer lezárja a conSzamla objektummal azonosított adatbáziskapc- 
solatot. Az adatbázis és a DataSet közötti kapcsolat ily módon 
csak a Fill() metódus végrehajtásának idején él, előtte, és utána 
nem. (Hát hiszen éppen ezért disconnected ez az egész...) 

Az SglDataAdapter objektum Fill() metódusa a mintapéldában bemu- 
tatott, tipikusnak tekinthető beállítás mellett többféle egyéb para- 
méterezést is elfogad. Ha csak az első paramétert adtuk volna meg, 
akkor a DataTable objektum , Table" névvel született volna meg. Ha 
már létezik egy DataTable objektumunk, akkor azt is megadhattuk 
volna az első paraméterben a DataSet objektum helyett. 


daPartner.Fill(dsPartSzla) " "Table" nevű DataTable 
daPartner.Fill(dtSzallito) " Ha már van ilyen dt 


Fontos figyelembe vennünk, hogy egy SglDataAdapter objektum 
a DataSetnek csak egyetlen DataTable objektumához kapcsoló- 
dik. Ha egy DataSet objektumnak ,Szallito", ,Szamla" és 
.Rendeles" adattáblákkal kell rendelkeznie, akkor ehhez három 
különálló SglDataAdapter hidat kell megépítenünk. 


A módosítások visszaírása, azaz a híd másik három sávjának 
elkészítése 

Az adatbázistól függetlenné vált DataSet, DataTable és DataRow 
objektumokban többféle módosítás is lejátszható. Koncentrál- 
junk most a tényleges adatokban, azaz a DataRow objektumok- 
ban végrehajtott változtatásokra! 

A változtatások tipikusan , felvitel-módosítás-törlés" jellegűek. 
Ennek megfelelően új sorok (új DataRow objektumok) építhetők 
be a rendszerbe, meglévő sorok adott mezőit módosíthatjuk, il- 
letve adatsorok törlését is kezdeményezhetjük. Az adatkarban- 
tartás programozott módon is megvalósulhat, de a leggyakoribb 
helyzet az, amikor az adott DataTable közvetett módon (pl. egy 
DataView objektumon keresztül) valamilyen felhasználói inter- 
fész elemhez (pl. DataGrid vagy DataList) kötődik. Ilyenkor a fel- 
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Az útsávok tényleges 
létrehozásához az 


Bsz 
j használó által begépelt adatmódosítások közvetle- 
nül átírják a DataTable-hez tartozó megfelelő 
DataRow objektum tartalmát. 
A ,közvetlen átírás" akár erős csúsztatásnak is tűnhet, 
ha mögénézünk a dolgoknak. A valóság ugyanis az, hogy 
ugyanabból a DataRow objektumból több verzió is létrejön a mó- 
dosításkor. Az Original verzióban például ott csücsül az eredeti 
adattartalom, míg a Current verzió az aktuális tartalmat hordozza. 
A ,közvetlen. átírás" tehát valójában a Current verziót babrálja. 
Akár programozott technikával, akár a felhasználó általi begé- 
peléssel módosul egy adattábla tartalma, előbb vagy utóbb 
szükségessé válik a módosítások átvezetése a központi adatbá- 
zisban. Ehhez először is meg kell építeni a híd másik irányba vi- 
vő sávját. A bekövetkezett változások háromfélék lehetnek 
(Insert, Update, Delete), ezért igazából nem is egysávos utat, 
hanem egy háromsávos sztrádapályát kell megalkotni. Mindhá- 
rom sávra természetesen csak akkor van szükség, ha új sor fel- 
vitelek, módosítások és sortörlések egyaránt előfordulhatnak az 
adattáblában. Magyarul, csak azokat a sávokat kell megépíteni, 
amelyeken számítani lehet adatforgalomra. 
Az útsávok tényleges létrehozásához az SglDataAdapter objektum 
InsertCommand, UpdateCommand 
és DeleteCommand tulajdonság- 
adatait kell a megfelelő SglCom- 
mand objektummal feltölteni. 


SgDataAdapter Az InsertCommand sáv működte- 
objektum téséhez egy olyan SglCommand 
objektumot kell készíteni, amelyik 

InsertCommand, egy INSERT SOL utasítást vagy egy 
UpdateCommand és tárolt eljárást tartalmaz. A tényle- 
gesen beillesztendő adatok 

DeleteCommand SglParameter — objektumokként 


tulajdonságait kell a 


kapcsolódnak az SglCommand ob- 


megfelelő SaglCommand jektumhoz. 
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Az UpdateCommand tulajdonság- 


objektummal adatba olyan SalCommand objektu- 
feltölteni mot kell bevinni, amelyik egy 


UPDATE SOL utasítást vagy egy ha- 
sonló funkciójú tárolt eljárást tartalmaz. Az adatbázisban módosí- 
tandó mezők itt is SaglParameter objektumokként jelennek meg. 

A DeleteCommand-beli SglCommand objektum egy DELETE SOL 
utasítást vagy egy megfelelő tárolt eljárást tartalmazhat. A tör- 
lendő adatsor beazonosításához szükséges mező vagy mezők itt 
is SglParameter objektumokként épülnek be a rendszerbe. 

Ha a szükséges útsávokat kiépítettük, akkor az SglDataAdapter 
objektum Update() metódusával elindítható a háromsávú adat- 
forgalom. Az Update() metódus paraméterében kell megnevezni 
azon adatsorok körét, amelyekre vonatkozóan az aktualizálást el 
akarjuk végezni. Néhány példa arra, hogyan lehet megfogalmaz- 
ni az aktualizálási feladatot: 


daPartner . Update(dsPartSzla) 


$  " A teljes DataSet-re vonatkozik 
daPartner.Update(dtSzallito) 

4 " Csak az adott DataTable soraira vonatkozik 
daPartner . Update(dsPartSzla, "Szallito") 

$ " Az előzővel megegyezik 
daPartner . Update(drTomb( ) ) 

b " Az adott DataRow() tömb adatsoraira szól 


Az Update() metódus a tényleges adatforgalom megindítása 
előtt megnyitja az InsertCommand, az UpdateCommand és a De- 
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leteCommand által igényelt adatbáziskapcsolatot. Ugyanaz a 
kapcsolati objektum (pl. conSzamla) használható mindhárom 
parancshoz egyidejűleg. A rendszer ezután sorra veszi a paramé- 
terben beazonosított adatsorokat (DataRow objektumokat), és 
kihalássza közülük azokat, amelyeknél a RowState tulajdonság- 
adat változásra utal. Azokat az adatsorokat, amelyeknél a 
RowsState értéke DataRowState.Added, az InsertCommand sávra 
tereli, vagyis ezekre egyenként meghívja az ott megadott 
INSERT SOL utasítást vagy a megfelelő tárolt eljárást. Azok az 
adatsorok, amelyeknél DataRowState.Modified érték szerepel a 
RowState tulajdonságban, az UpdateCommand sávon indulva 
érik el a megfelelő UPDATE SOL utasítást, illetve az erre a célra 
megírt tárolt eljárást. A DataRowState.Deleted jelzéssel ellátott 
adatsorok pedig a DeleteCommand-hoz kapcsolt DELETE SOL pa- 
rancsot hajtják végre. Az aktualizálási folyamat végén a rend- 
szer bezárja a megnyitott adatbáziskapcsolato(ka)t. 

Az alábbiakban nézzünk egy példát az UpdateCommand feltöltésére: 


Dim conSzamla As New SglConnection( 

4 "user id-sa;password-haliho;" 8. 
"database-Szamla;data source-Gepl") 

Dim cmdPartner As New SglCommand( 

b "Select t From Partner Where PaTipuszl", 

conSzamla) 

Dim daPartner As New SglDataAdapter 

Dim dsPartSzla As New DataSet 

Dim cmdőodos As New SaglCommand( 

6 "UPDATE Partner SET " 8 
"PartAzon-eID, PartNev-eNev WHERE " 8 
"PartAzonseEredID", conSzamla) 

cmdModos . Parameters .Add(New SgliParameter( 

B "GID", SalDbType.Int32, 4, 
ParameterDirection.Input, False, OD, 0, 
"PartAzon", DataRowVersion.Current, Nothing)) 

cmdModos . Parameters .Add(New SglParameter( 

$ "eNev", SglbbType.Char, 30, 
ParameterDirection.Input, False, DO, 0, .. 

"PartNev", DataRowVersion.Current, Nothing)) 
cmdModos .Parameters.Add(New SglParameter( 

G  "eEredID", SglDbType.Int382, 4, 
ParameterDirection.Input, False, O, 0, 
"PartAzon", DataRowVersion.Original, Nothing)) 

daPartner . SelectCommand - cmdPartner 

daPartner . UpdateCommand - cmdíodos 
daPartner.Fill(dsPartSzla, "Szallito") 
" Itt történik meg a Szallito adattábla 

4 módosítása 

daPartner.Update(dsPartSzla, "Szallito") 

dsPartSzla.AcceptChanges( ) 


A fenti kódrészletben a módosítások visszavezetésére létrehoz- 
tunk egy cmdModos nevű SglCommand objektumot. Ez az objek- 
tum a conSzamla adatbáziskapcsolaton keresztül egy UPDATE 
utasítás végrehajtását célozza meg. Az UPDATE SOL utasítás há- 
rom paramétert vár: a partner eredeti azonosítóját ((DEredID), 
a partner esetlegesen megváltoztatott azonosítóját ((2ID) és a 
partner új nevét ((DNev). (A példa kedvéért most egy pillanatra 
vonatkoztassunk el attól, hogy mennyire nem egészséges dolog 
megengedni egy tábla egyedi azonosítójának megváltoztatását. A 
lényeg az, hogy akár egy ilyen módosítás is visszavezethető az 
eredeti adatbázisba.) Három SalParameter objektumot kell tehát 
létrehoznunk és hozzákapcsolnunk a Parameters.Add() metódus 
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segítségével a cndModos objektumhoz. Az SglParameter objek- 
tum konstruktormetódusai közül a mintapéldában látható tízpa- 
raméteres változat a legtipikusabb, ezért ezen keresztül érde- 
mes megismerkedni az egyes tulajdonságadatok szerepével. 


Dim Paral As New SglParameter(ParameterName, 
SgilDbType, Size, Direction, IsNullable, 
Precision, Scale, SourceColumn, SourceVersion, 
Value) 


Az alábbi táblázatból kiolvasható az egyes tulajdonságadatok 
tartalma: 


Tulajdonság Leírás 


ParameterName A paraméter neve. 

SglDbType A paraméter adattípusa. 

Size A paraméter mérete byte-ban. 
Direction A paraméter iránya tárolt eljárásoknál: 
Input, Output, InputOutput, 
ReturnValue. 

A paraméter fogadhat-e NULL értéket. 
Alapértelmezésben false az értéke, 
azaz nem fogadhat NULL-t. 

A Value adatban szereplő számjegyek 
maximális száma. 

Scale A Value adatban szereplő szám tize- 
des jegyeinek száma. 

Annak az oszlopnak a neve a 
DataTable objektumon belül, ahonnan 
az adatot venni kell az Update() 


metódus végrehajtása során. 


IsNullable 


Precision 


SourceColumn 


SourceVersion A DataRow objektum verziója, 
ahonnan az adatot venni kell. 
Value A paraméter értéke. Inputparaméte- 


reknél a parancs végrehajtása előtt 
meg kell adni. Outputparamétereknél 
és a visszatérési értéknél ebben kap 
juk vissza a tárolt eljárás vagy a függ- 
vény által juttatott adatot. 


Mindezen információk birtokában kanyarodjunk vissza az erede- 
ti UpdateCommand feladathoz, és nézzük meg, hogyan kell beál- 
lítani az egyes paramétereket a feladat korrekt elvégzéséhez! 

Az első paraméterre az UPDATE utasításban a ,(DID" néven hi- 
vatkozunk, és a konkrét paraméterértéket (a Value tulajdonság- 
adatot) a ,Szallito" nevű DataTable objektum ,PartAzon" nevű 
DataColumn oszlopából kérjük kiemelni annál a sornál, amelynél 
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valamilyen módosítást észlelt az SgIDataAdapter ob- 
jektum Update() metódusa. Mivel az UPDATE utasí- 
tás SET opciójában a módosított értéket várjuk, a Da- 
taRowVersion.Current által azonosított adatot kérjük. 
A második paraméterre a , 2DNev" néven hivatkozunk az 
UPDATE utasításban. A konkrét adatot a , PartNev" nevű oszlop- 
ból kérjük kiemelni. Itt is az esetlegesen módosított értékre van 
szükségünk, ezért DataRowVersion.Current értéket állítunk be az 
SOLParameter konstruktorának kilencedik paraméterében. 

A harmadik paramétert az UPDATE utasítás WHERE feltételében 
használjuk , DEredID" néven, és ezzel kell rátalálnunk az erede- 
ti partnerrekordra - még akkor is, ha a partnerazonosítót go- 
nosz módon megváltoztatták. Itt tehát a , PartAzon" oszlopnak 
a DataRowVersion.Original verzióját kell kiemelnie a rendszer- 
nek, és beépítenie az UPDATE utasításba. 

Ha az így összeállított SaICommand objektumot hozzákapcsoljuk 
az UpdateCommand tulajdonságadathoz, akkor a daPartner.Up- 
date() metódus minden egyes módosított adatsornál megfele- 
lően kitölti a paraméterek Value adatát, majd meghívja az 
UPDATE parancsot. Ha új sorokat is felvittünk, és nincs megad- 
va a megfelelő InsertCommand, akkor futás közbeni hibát ka- 
punk. 

Az Update() tényleges végrehajtását követően a DataTable-hez 
tartozó adatsoroknál is célszerű lehet bejelölni az aktualizálás 
tényét, hogy a következő Update() már ne vigye át ismételten 
az eredeti módosításokat. Ehhez az adott DataTable objektum 
AcceptChanges() metódusát kell meghívnunk. Az AcceptChan- 
ges() metódus az összes Added és Modified státuszú adatsort 
Unchanged státuszúra alakítja át, a Deleted jelzésű sorokat pe- 
dig kitörli. Az AcceptChanges() kiadható DataSet és DataRow 
szinten is. Az előbbi esetben a DataSethez tartozó összes adat- 
táblára végrehajtja az adott műveletet, az utóbbi esetben csak 
egyetlen adatsorra történik meg a módosítások véglegesítése. 


Nem kell persze mindenáron összekoszolni a kezünket a hídsávok 
fáradságos kézi megépítésével, hiszen a Data Adapter 
Configuration Wizard elvégezheti helyettünk a piszkos munkát. 
Előállítja a szükséges programkódot, sőt még tárolt eljárást is ír 
helyettünk, ha akarjuk. Nem árt azért tudni azt, hogy mennyi rész- 
let pontos összeillesztése kell egy ilyen adathíd felállításához. 


Endrődi Tamás 
endrodi2okk.szamalk.hu 
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Exchange 2000 


Felhasználók, 


csoportok, címlisták 


Az előző szám végén ott tartottunk, hogy a felhasználók beállításai jönnek. 
Jöjjenek, és nemcsak a felhasználók, hanem az e-mail címmel rendelkező 
egyéb objektumok - tehát a kapcsolatok (Contacts) és az e-mail címmel 
rendelkező csoportok - tulajdonságait is megnézegetjük ebben a részben. 


Felhasználók tulajdonságlapjai 

Arról már az előző számban is szó volt, hogy attól függően, mi- 
lyen nézetet választunk az Active Directory Users and Computers 
konzolon, mindig más tulajdonságok láthatók. Ha nincs bekap- 
csolva a , View Advanced Features", Gipsz Jakab tulajdonságlap- 
ja így jelenik meg: 


3j3 
MemberOf ]/ Diakn ]/ Environment ] Sessions ] Remote control ] 
Tetminal Services Profile 1 Exchange General l 
E-mad Addresses Exchange Featurez Hi 


l 
General ]) Address ]/ Account ] Profie ] Telephones ] Organization [/ 
EZ iebőpzz 


5 Gipsz Jakab egyszerűbb nézetben 


Mivel az Active Directory az Exchange címtára, a felhasználók beál- 
lításai közt sok olyan van, amelyeket ha kitöltünk, a levelezőprog- 
ramból nézve megjelennek a címlistában. Ilyenek az Organization, 
az Address vagy a Telephones tulajdonságlapon beállítható adatok. 
Izgalmasabb az E-mail Addresses tulajdonságlapja, ahol a felhasz- 
nálóhoz rendelt e-mail címek találhatók. Házirenddel állítható, 
hogy milyen típusú címek jöjjenek létre a postaládával egy időben. 
Alapértelmezésben minden felhasználó számára egy SMTP és egy 
X400 cím jön létre. Egy típusból (maradjunk az SMTP-nél) több vál- 
tozatot is meg lehet adni, ilyenkor egyet mindig ki kell nevezni el- 
sődlegesnek (ez látszik az elküldött levelek fejlécében) , a többi cím- 
re a felhasználó csak fogadni tud levelet. 





5 Gipsz Jakabnak is két SMTP típusú e-mail címe van 


A vastagon szedett az elsődleges cím, a gipsz.jakab kezdetű pe- 
dig alárendelt. (A JGipsz volt az Alias, amit a postaláda létrehozá- 
sakor megadtam.) Minden esetben az Aliast fogja a varázsló a lét- 
rehozott címben a (2 elé tenni. A postaláda létrehozása után rög- 
tön nem látszanak az e-mail címek, várni kell, míg a Recipient 
Update Service frissíti a címeket, de lehet őt sürgetni is. 

Az SMTP és az X.400-as cím mellett lehetőség van Lotus, 
cc:Mail, MS Mail, Groupwise címek létrehozására is, amiket ak- 
kor használunk, ha az Exchange-et más levelező rendszerekkel, 
speciális csatolók segítségével kapcsoljuk össze. Az SMTP az 
Interneten keresztüli levelezés ,de facto" szabványa, SMTP cím- 
zéssel utaznak a levelek az Interneten. 

Az X400 címzést más X400 rendszerekkel való közvetlen kapcso- 
lattartásra használjuk. 
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A felhasználók General lapján is van egy E-mail tulajdonság, 
amely az E-mail Addresses fülön található elsődleges címre mu- 
tat. Ha az egyiket átírjuk, megváltozik a másik is. 

Az Exchange General tulajdonságlapon megnézhetjük, hogy az 
adott felhasználó postaládája melyik szerveren található. Moz- 
gatni a Move Mailbox varázslóval lehet. A postaláda létrehozá- 
sakor megadott Aliast is meg tudjuk itt változtatni. Ennek nem 
kell azonosnak lennie más nevekkel, általában az e-mail cím (2 
előtti részével egyezik meg. Már volt arról szó, hogy a postalá- 
da létrehozáskor megadott Alias lesz az elsődleges e-mail cím- 
ben is. Ha utólag megváltoztatjuk az Aliast, az e-mail cím már 


nem változik vele. 

Ha POP3 segítségével húzo- Minden 

gatjuk le a leveleket egy felhasználóra 

Exchange kiszolgálóról, elő- ebe dás 

fordulhat, hogy egy felhasz- külön-külön be 

náló nem tud bejelentkezni. lehet állítani az 
általa elküldhető 

és fogadható 


Ez abból adódhat, hogy az 
Alias és a felhasználó login 

levelek maximális 
méretét. 


neve - pontosan a User Logon 
Name (Pre-Windows 2000) - 
nem egyezik meg. Ilyenkor 
ezeket vagy szinkronba kell 
hozni (kézzel), vagy a POP3- 
as csatlakozáskor ctartományztclogin névetsAliasz hármast 
kell megadni bejelentkezési névként. 

Az Exchange General Delivery Restrictions lapján állíthatók a 
levélküldéssel és fogadással kapcsolatos beállítások. 

Minden felhasználóra külön-külön be lehet állítani az általa el- 
küldhető és fogadható levelek maximális méretét. Természete- 
sen nemcsak egyesével lehet beállítani ezt, hiszen az Exchange 
globális beállításai közt is megtaláljuk a levélméret-korlátozást. 
Itt csupán ahhoz képest tehetünk kivételeket. Szintén itt hatá- 
rozhatjuk meg, hogy egy felhasználó kitől kaphat levelet. Akkor 
tudunk megadni idegen címeket, ha azokat előzőleg Kapcsolat- 
ként (Contact) felvesszük az AD-ba. 

A Delivery Options ablakban lehet beállítani, hogy az adott fel- 
használó nevében egy másik tudjon levelet küldeni: ez a ,Send 
on behalf". Ez nem jelenti azt, hogy a postaládájához hozzáfér, 
csupán azt, hogy a felhatalmazó személy nevében írhat levelet 
(a From mezőben megadhatja annak nevét). Ilyenkor a megka- 
pott levél From mezőjében pédául ezt olvassuk: , Gipsz Jakabné; 
on behalf of; Gipsz Jakab". Ez azt jelenti, hogy Gipszné Gipsz 
Jakab nevében küldte az üzenetet. 

Ugyanitt lehet beállítani a felhasználó leveleinek más címre to- 
vábbítását. Ha külső címre szeretnénk továbbítani, akkor előző- 
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leg fel kell venni egy Kapcsolatot (Contact) a külső e-mail cím- 
mel, majd meg kell adni továbbítási célként. Így az összes levél 
arra a címre utazik tovább. (Lehetőség van arra, hogy a postalá- 
dában is megőrizzük a továbbított leveleket, ahhoz a ,,Deliver 
messages to both..." checkboxot be kell jelölni. ) 
CEZSZZETEZTEE TEK TESEKSSKEEE 212 

1 Send on behal———————— 


Grant thiz permission to: 
1 E Adminsttatot 
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Forwaráng addtess 
G Nome 
C Forward to: 





Lsd messöges to tatk fi 


Fiácíólett inka sz ge e e 


€ Megémum recipients: 


] 6 [eddakími 





a Exchange General — Delivery Options 


Végül még egy lehetőség: szabályozhatjuk, hogy egy felhasználó 
égyszerre hány címre küldhet levelet. Alapértelmezésben a , Maxi- 
mum recipients" száma 5000 - ez a Global Settings -2 Message 
Delivery lapon található a System Managerben. Ha ez bizonyos 
helyzetekben nem megfelelő, akkor egyes felhasználóknak többet 
vagy kevesebbet állíthatunk be. 

Az Exchange General - Storage Limits lapon a postaládák méretét 
illetően kivételeket lehet tenni az Exchange házirendhez képest. 
Ugyanúgy mint a házirendben, itt is meg lehet adni egyrészt egy 
küszöbméretet, aminek átlépése után figyelmeztető üzenetet kap 
a felhasználó, másrészt egy olyan határt, ami fölött nem tud le- 
velet küldeni, harmadrészt a végső határt, aminek elérésekor 
mindaddig nem tud levelet küldeni és fogadni, amíg nem csök- 
kenti a postaláda méretét a megengedett határ alá. 

Ha egy olyan felhasználónak próbálunk levelet küldeni, akinek már 
betelt a postaládája, rögvest egy üzenetet kapunk vissza, amiben 
az áll, hogy vagy megtelt a címzett postaládája, vagy túl nagy le- 
velet próbálunk küldeni, amit a beállítások nem engednek meg. 
Központilag is, és felhasználónként is lehet állítani azt, hogy a 
postaládából letörölt leveleket - pontosabban a Deleted Items 
mappából törölt dolgokat - meddig tartsa meg visszaállítható 
formában az Exchange. Ez a ,Deleted Item Retention" értéke, 
ami szintén a Storage Limits lapon található. 

Az Active Directory Users and Computers , Advanced Features" mód- 
jában található az Exchange Advanced lap. Itt adhatunk meg egy- 


szerű, ékezetes vagy egyéb sk ús 8. 
extra karaktereket nem tar- Központilag IS, 


talmazó nevet a felhaszná-- és felhasználóként 
lóhoz, ami akkor érdekes, . I h áll e 
ha valamilyen levelezőprog- is lehet állítani azt, 
ram nem tudja az extra ka- hogy a 
raktereket megjeleníteni. postaládából 
letörölt leveleket 
meddig tartsa meg 
visszaállítható 
formában az 
Exchange. 
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Pubished Certiicates ]  MemberOt ] Diskn ] Otiect [/ Secuny ] 
Environment ] Sessions ] Remote contol [Terminal Services Proífte ] 
Exchange General 1 E-mad Addresses l 
General ] Adorezs [/Account ] Profte ] Telephonez ] Organization [ 
Exchange Features 


Single display name 
TT Hide írom Exchange address fstz 
TT Downgzade high piosíty mail bound for 400 


View and modíly custom attibutes Cum Alrbutes. 
Configure the protocols used ta accest 

je Piolocol Settings. 
Configure server and account information jálngi. 
for intemet locator service EB 

View and modíy permézsionz to s0cess 

ve Malbox Rights... 


Admerislratíve Group: Fist Adminéstratíve Group 





5 Gipsz Jakab , Exchange Advanced" lapja 


Ha el akarjuk rejteni a felhasználót a címlistákból, akkor kell a 
Hide from Exchange address lists" elé pipát tenni. A Custom 
Attributes gomb mögötti lapon egyéb tulajdonságokat lehet 
megadni, ha a meglevő attribútum-készlet esetleg nem lenne 
elég. Sajnos az itt megjelenő tulajdonságok nevét nem lehet 
megváltoztatni, csupán értéket adhatunk nekik. Ezek a tulaj- 
donságok tulajdonképpen az Exchange 5.5 rendszerekkel való 
kompatibilitás fenntartása miatt léteznek. Előfordulhat hogy az 
5.5-ös és az Exchange 2000 közötti replikáció megváltoztathat- 
ja a neveket. Ha azt szeretnénk, hogy a felhasználó adatai közt 
megjelenjenek más tulajdonságok is, az AD sémát kell bővíteni. 
A Protocol Settings lapon felhasználónként lehet szabályozni a 
HTTP, IMAP és POP3-as elérést. Ezek a beállítások a System 
Managerben központilag állíthatók, itt kivételeket tehetünk a 
szerver beállításaihoz képest. Alapállapotban mindenkinek en- 
gedélyezve van mind a három protokollon keresztüli csatlako- 
zás, amit felhasználónként letilthatunk. 

A HTTP protokoll nem sok beállítással kényeztet minket: tiltani vagy 
engedélyezni lehet az Outlook Web Access-elérést. Az IMAP4 és POP3 
beállításai ennél többet engednek. Ha szükséges, felülbírálhatjuk a 
szerverről örökölt beállításokat, egyénileg szabályozhatjuk a proto- 
kollhoz kapcsolódó levélformátumokat, karakter-beállításokat. 

Az ILS Settings lapon beállítható Internet Locator Service kiszolgá- 
ló és név akkor használatos, amikor a felhasználó az Outlookból 
próbál online találkozót összehozni. 

Az Exchange Advanced lapon az utolsó lehetőség a postaládá- 
hoz tartozó jogosultság szabályozása, a Mailbox Rights. Egy 
frissen készített felhasználó esetén nem látszik más, csupán a 
SELF , Full Mailbox Access". Amint ez a felhasználó belép, vagy 
levelet küldünk neki, megjelennek a valódi jogok, amelyek csak- 
nem teljes egészében öröklődéssel kerülnek ide: a pipák szürkén 
látszanak. Ha egy felhasználónak , Full Mailbox Access" jogot 
adunk, be tud lépni a másik felhasználó postaládájába. Csupán 
az Outlook profilt kell beállítani, és már működik is. 

Eddig már kétszer volt arról szó, hogyan tud egy felhasználó más ne- 
vében levelet küldeni. Az egyik a ,Send on Behalf" a másik , Full 
Mailbox" jog. Van egy harmadik módja is, méghozzá a , Send As" jog. 
Ezt a beállítást a felhasználó objektumának Security lapján találjuk. 
Ha mondjuk Gipsznének ,Send As" joga van Gipsz Jakab postaládá- 
ján, levélküldéskor a From mezőbe Gipszné a sajátja helyett Gipsz Ja- 
kab nevét tudja írni, és a levélből nem fog kiderülni, hogy azt való- 
jában Gipszné küldte. Tessék óvatosan bánni ezzel a joggal! 
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A csoportok és kapcsolatobjektumok tulajdonság- 

lapjai kevés beállítható pontot tartalmaznak. 

Ugyanúgy van Exchange General és Exchange 
Advanced valamint E-mail Addresses lap, rajtuk keve- 
sebb illetve kicsit más beállítási lehetőséggel. 


A címlisták 

Amikor levelet írunk, címlistából választhatjuk ki a címzett ne- 
vét. A címlisták tartalmazzák az összes e-mail címmel rendelke- 
ző objektumot, kivéve amelyeken szándékosan megtiltjuk, hogy 
látszódjanak a címlistákban. Alapértelmezésben is többféle cím- 
lista található az Exchange-ben. 








5 Címlisták az Exchange-ben 


A címlistákat a System Managerben a Recipients alatt találhat- 
juk, van belőlük jó pár: úgy látszanak, mintha konténerobjektu- 
mok lennének. Ha megnézzük egy ilyen objektum tulajdonságait, 
(jobb klikk - properties) látható, hogy valójában csak egyszerű 
objektumok. A címlisták LDAP lekérdezéseket tartalmaznak. Az 
Active Directoryból szűrik ki a megfelelő objektumokat. A legis- 
mertebb talán a Default Global Address List, vagy röviden GAL, 
amely egymaga tartalmazza az összes e-mail címmel rendelkező 
objektumot. Leggyakrabban ezt használjuk. Alapértelmezésben 
külön címlista van a felhasználóknak, a csoportoknak, a kapcso- 
latoknak, illetve a címmel rendelkező nyilvános mappáknak is. 

Ezeken kívül van még egy, az , Offline Address Book", amely letölt- 
hető az ügyfélgépekre, így akkor is tudunk leveleket írni, ha nem 
vagyunk hálózatközelben. Az így írt leveleket az Outboxból a követ- 
kező csatlakozáskor az Outlook automatikusan elküldi. Az 
alapértelmezett offline címlistának a GAL az alapja, hisz ez a leg- 
teljesebb lista. Természetesen ezt a típusú címlistát is alakíthatjuk. 


Default Global Address List 
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5 A GAL LDAP lekérdezése 


Mindezeken kívül rendkívül rugalmasan, az objektumok típusá- 
ra, tulajdonságaira szűrve mi magunk is készíthetünk egyedi 
címlistákat, mintha csak az AD-ban keresnénk egy objektumot. 
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LDAP szűrés a címlistához 

A General lapon ki tudjuk választani az objektumtípusokat, a 
Storage lapon azt, hogy melyik szerverről és adatbázisról van 
szó. A képen látható Advanced lapon pedig minden egyes ob- 
jektumhoz tartozó összes tulajdonság alapján állíthatunk felté- 
teleket. Ha több feltételt szabunk, azok ÉS kapcsolóval lesznek 
összekötve. Ha VAGY kapcsolót szeretnénk a feltételek közé, saj- 
nos (?) egyedi LDAP lekérdezést kell készítenünk. A legfelső le- 
gördülő listából az Exchange Recipients helyett a Custom Search 
lehetőséget kell kiválasztani, és már írhatjuk is az LDAP lekér- 
dezést, melynek RFC 2254 kompatibilisnek kell lennie, egyéb- 
ként nem fog működni. 

Mivel az Exchange címtára az Active Directory, a címlisták elemei is 
onnan kerülnek ki. A System Attendant szolgáltatás része a Recipient 
Update Service, röviden RUS, amely felelős a címlisták tartalmáért. 
Minden objektumnak - felhasználónak, csoportnak, nyilvános 
mappának, kapcsolatnak - van egy úgynevezett showInAddress- 
Book tulajdonsága, amelynek értéke megadja, hogy az adott ob- 
jektum mely címlistákban fog látszani. 





CN-contact cccc Propertfes ES 2121 
Altributes ] Security] 


Pathc LDAP://biga.hellnet/CNscontact cccc.ÜlJzexam DCshellDCzn 


Cass: contact 
Select which properties to view: . JOptional d 
Select a property to view: shovdnáddreszBook bud 
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5 Egy kapcsolat ShowlnAddressBook tulajdonsága 


Amikor a rendszergazda létrehoz egy címlistát, akkor nem tesz 
mást, mint szűrőket definiál a System Managerben. Ezután jön a 
RUS, ami a szűrő alapján minden egyes érintett objektumon módo- 
sítja a showlnAddressBook tulajdonságot. Ez frissül a Global 
Catalog szervereken, és amikor a felhasználó az Outlookból a cím- 
listában keres valakit, akkor tulajdonképp onnan, a Global Catalog 
szervertől kapja az információt. 

A RUS-nak vannak egyéb feladatai is. Például a házirend alapján frissí- 
ti az e-mail címek beállításait stb. Kétféle RUS objektum van a System 
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Managerben. Az Enterprise RUS az AD konfigurációs konténerében le- 
vő objektumok e-mail címeit frissíti. A másik a tartományhoz kapcso- 
lódik, az ott levő e-mailes objektumok címeinek frissítését végzi, va- 
lamint a címlistákat kezeli. Minden egyes Exchnage 2000-et tartalma- 
zó Windows 2000 tartományhoz tartozik egy ilyen RUS. 
Alapértelemzésként a RUS percenként fordul az Active 
Directoryhoz változásokat szimatolva, de (puszta kézzel) mi is 
frissíthetjük vagy újraépíttethetjük a címlistát. 

Újraépítés esetén a teljes címlistatagság felülbírálásra kerül, 
míg frissítéskor a csupán a változásokkal frissül a lista. 

Annyi címlistát csinálhatunk, amennyit csak szeretnénk. Létre- 
hozhatunk több GAL-t is, egy felhasználónak azonban egy idő- 
ben csak egy fog látszani. Hogy melyik, az attól függ, hogy me- 
lyikhez van jogunk, melyiknek tagja a felhasználó - és függ a 
címlista méretétől is. Ebben a sorrendben. Vagyis ha több olyan 
is van, amelyikhez egy felhasználónak joga van, az fog látszani 
közülük, amelyiknek a felhasználó maga is tagja. Ha többnek is 
tagja, a méret a döntő, a nagyobb fog győzni. 

Minden címlistához meg lehet adni, hogy ki láthatja a tartal- 
mát. Ezt a lista Security lapján tehetjük meg. Az Open Address 
List jog kulcsfontosságú. Az láthatja a címlista tartalmát, aki- 
nek ez a joga megvan. Ha nem akarjuk minden egyes címlistán 
egyedileg állítani a megfelelő jogokat, akkor a felette levő kon- 
téneren, például az All Address List Security lapján egyszerre ál- 
líthatjuk. A jogok öröklődni fognak az alatta lévőkre. 

Ha az egész címlistát el szeretnénk tüntetni a kíváncsiskodók 
elől, nem elég megvonni az Open Adderss List jogot a listán, 
ugyanis ezzel csak a címlista tartalmát tüntetjük el, de magát a 
címlistát nem. Ehhez egy szinttel feljebb kell lépni, és ott kell 
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rejtegetni. Létrehozunk egy üres címlistát, amit a 
valódi címlisták tárolására használunk. Az alábbi 
ábrán ez Bizalmas néven látható. 





5-8 all address Lists 
ÉM All Contacts 
a-8 All Groups 
H-E All Users 
m- 8 Public Folders 
5-8 Bizalmas 


— BEEN 


5 A , Külsősök" címlista elrejtése 




















Ebben kell létrehozni a rejtett címlistát - ez az ábrán a , Külső- 
sök" listája. A jogosultságok öröklődése miatt az , Authentica- 
ted Users" csoportnak kezdetben joga van minden címlistához. 
Ha csak a vezetés számára szeretnénk láthatóvá tenni a Külső- 
sök címlistáját, le kell vennünk az ,Authenticated Users" cso- 
portot a jogosultsággal rendelkezők közül, és helyette a veze- 
tőknek létrehozott csoportnak kell megadni az Open Address 
List jogot. Mégegyszer: mindezt nem a Külsősök címlistán kell 
tenni, hanem egy szinttel felette, a , Bizalmas" lista Security 
lapján. Persze a ,Bizalmast" ettől még látják mások is. Ha ezt is 
tiltani szeretnénk, akkor még feljebb kell menni, és az All 
Address Lists szintjén kell a jogokkal babrálni. 
A házirendekkel folytatjuk... 
Dorner Csilla 
MCSE 





BON8S. 8.5. 





"oTeuzseUuTBaJ / 


"yo3Ju4odosa 


MBISTIUTD 


3b 





Server és web storage system 


37 


Exchange 2000 


" Server és web storage system 


Korábban bemutattuk, hogyan lehet az Exchange2000 Server Web Storage System-ét 
(WSS) elérni ADO-n (ActiveX Database Objects) keresztül. Most a .NET keretrendszer 
segítségével állunk neki a feladatnak. Egyelőre azonban - sajnálatos módon előre 
láthatatlan ideig - ADO.NET-ben nincs támogatás az Exchange2000 Server és a WSS 
elérésére. Ezért más, .NET alatt is használható megoldások után kell néznünk. 


Az utóbbi időben nagy változások történtek: sokak szerint a 
.NET világa olyan a natív kódokhoz és a korábbi programozási 
módszerekhez képest, mint a Windows megjelenése a DOS-hoz 
képest. Ezzel a , forradalommal" együtt természetesen az ADO is 
megváltozott, s mint minden ilyen esetben, némi inkompatibi- 
litás is felütötte a fejét. Ez abból adódik, hogy az ExOLEDB 
providert nem tudjuk felhasználni az ADO.NET menedzselt osz- 
tályaiban (pl. Connection). Lássuk a többi lehetőséget! 


A WebDAV (Web-based Distributed Authoring and Versioning) 
A WebDAV a HTTP protokoll egyik kiterjesztése, amely lehetővé teszi, 
hogy távoli kiszolgálókon található állo- 
mányokat érjünk el, szerkesszünk, olvas- 
sunk, módosítsunk stb. Fő célja - a fel- 
használók igényeinek megfelelően - az 
együttműködés elősegítése a különböző 
webes alkalmazások között. Egyik leg- 
fontosabb tulajdonsága, hogy a HTTP 


Az ADO helyét kiváltó 
megoldások közül kettőt 
fogunk megvizsgálni, közös natív és a menedzselt kódok mintha 
tulajdonságuk, 


WebDAV kérést továbbít az Exchange2000 Server felé (amely fi- 
zikailag akár másik gépen is lehet). Az Exchange válasza XML for- 
mátumú, mint ahogy azt el is várjuk. Ezt a .NET FrameWork fel- 
dolgozza (pl. egy DataSet-be tölti, táblázatba vagy file-ba írja), 
majd visszaküldi a kész adathalmazt a kliensoldali felhasználó- 
nak (pl. egy weboldal formájában). 


Az XMLHTTP 

Az XMLHTTP első ránézésre jó megoldásnak tűnhet a WSS (Web 
Storage System) elérésére. Működik. Hátránya, hogy COM objek- 
tum. Ez azt jelenti, hogy használhatjuk ugyan .NET-es kódokból, 
viszont nem tartozik a FrameWork ha- 
táskörébe. Ez azért lényeges, mert az 
adattípusok, metódusok, hibakezelés 
stb. nagyon eltérő a két világban: a 


nem is ugyanazon a bolygón lennének. 
Az átjárás biztosítása a COM interop 


protokollt használja, így mindenhonnan hogy WebDAV-ra épülnek... feladata, erről bővebben az MSDN-ben 


könnyedén elérhető, és egyszerűen hasz- 

nálható. Ráadásul a kommunikáció XML 

formátumban folyik, ami szintén ismerős és kedvelt mostanában. 

Az ADO helyét kiváltó megoldások közül kettőt fogunk megvizs- 
gálni, közös tulajdonságuk, hogy WebDAV-ra épülnek, működé- 
sük hasonló elvek alapul: 


HTTP kérés 
6 [ [dl 
——— 
HG 
ee mm EZ Válasz szen CENTI 
Felhasználó Munkaállomás :NET Framework 


XML válasz 
59199 AVagaM 


Exchange 2000 
Server 


5 A WSS adatainak elérése WebDAV-on és .NET FrameWork- 


ön keresztül 


A .NET FrameWork-höz elérkezik a kérés (pl. egy ASP.NET lap). A 
CLR (Common Language Runtime) feldolgozza azt, és egy 
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olvashatunk [1], [2]. 

Nyilván előnyei is vannak az XMLHTTP 
használatának, egyébként senki emberfiának (-lányának) nem 
születne az az elképesztő ötlete, hogy kipróbálja, mit tud. Hogy 
ez mégis megtörtént, annak az az oka, hogy a COM-os objektu- 
mok a régi világból ismerősek, használatukat megszoktuk, talán 
néhányan még meg is szerettük (?). Vágjunk tehát bele! 
Először is azt kell tudni, hogy az XMLHTTP30 nevű interfész az 
MSXML2 névtérben lakik (msxml.dill), ezt kell referenciaként 
beimportálni a programunkba, hogy az működőképes legyen. 

A WebDAV nagyon sokféle adatelérést tesz lehetővé. Ez a sokol- 
dalúság a különböző metódusokon keresztül valósul meg, né- 
hány ezek közül: 


DA Let Aie ei 
COPY Másolatot készít a megnevezett erőforrásról 
a célhelyre. 


DELETE Törli a megnevezett erőforrást. 

MOVE Átmozgatja a megnevezett erőforrást 
a célhelyre. 

MKCOL Új collectiont hoz létre. 

PROPFIND Az erőforrás jellemzőivel (properties) 
tér vissza. 

PROPPATCH Az erőforrás jellemzőinek módosítása. 

SEARCH Keresés a WSS-ben. 


2oo2. os. Tlecnnet 


Részletesebb leírás magazinunk 2001/IX. számában, a szabvá- 
nyok rovatban olvasható, a metódusok teljes listája az MSDN- 
ben megtalálható [3]. 

Lássuk először a keresés megvalósítását, hiszen talán ez a legalap- 
vetőbb elvárásunk. A következő kódrészlet ezt hivatott megoldani. 
Első lépésként meg kell adnunk azt a WSS mappát, ahol az el- 
érendő adatok találhatók: 


string SURL - "http://myserver/public folder/"; 

A kérés felépítése a következőképpen néz ki: 
StringBuilder sduery - new StringBuilder ( ) ; 
sduery.Append(e"C?xml versions"1.0D7?2"); 
sduery.Append( "£g:searchreguest xmlns:g-"DAV:"2"); 
sAuery .Append( "£g:sg12"); 

sduery.Append(" SELECT WV" DAV:displaynameN" "); 
sduery.Append(" FROM XN" ot SURL § "AT O"); 

sduery .Append( "£/g:sgi2"); 

sduery . Append( "£/g:searchreguest?2" ) ; 


Természetesen vesszővel elválasztva több jellemzőt is megadhatunk 
a SELECT után (akár SELECT "-ot is használhatunk) , WHERE szűrőfel- 
tételeket szúrhatunk be, sorrendezhetjük az eredményhalmazt 
(ORDER BY), stb., az SOL-ből megszokott szintaxisnak megfelelően. 
De hogyan jut el a kérés a szerverhez, és hogyan kaphatunk vá- 
laszt onnan? Itt jön a képbe az XMLHTTP. 


XMLHTTP3O davKeres - new XMLHTTP3UOC(); 
davKeres. open ( " SEARCH", sURL, false, 

4 öe"myserverNuser", "password" ); 

davKeres . setReguestHeader ( "Content-type: " , 
4 "text/xml" 972 

davKeres.send( sduery ) ; 
Console.Write(davKeres.ResponseText ) ; 


Létrehozunk egy példányt davKeres néven, majd az open meg- 
hívásával beállítjuk a megfelelő metódust (SEARCH), az URL-t, 
ahol a keresést végezni kell (5URL), illetve megadni a hozzáfé- 
rést kezdeményező felhasználó azonosítóját és jelszavát. Na- 
gyon fontos a fejlécben megadnunk (setReguestHeader), hogy 
XML típusú adatot küldünk (text/xml). 

A kérést csak ezek után (a send meghívásával) küldhetjük el, 
amelynek paraméterül átadjuk a lekérdezést tartalmazó stringet. 
A kiszolgáló válasza ezek után a ResponseStream jellemzőn ke- 
resztül érhető el. Ennek további felhasználásáról, alkalmazásá- 
ról a későbbiekben lesz szó. 

Érdekességképpen megmutatom, hogyan lehet e-mailt generál- 
ni, és állományokat csatolni hozzá a WSS-ben. Mindezt két lé- 
pésben oldjuk meg: 

Először a kereséshez hasonlóan egy kérést kell felépítenünk egy 
stringben, amit majd elküldhetünk a szervernek. Természetesen 
most nem lesz SELECT-ünk, hiszen nem keresni szeretnénk a lé- 
tező dokumentumok között, valamint az XML kérés formátuma 
és tartalma is eltér az előzőektől: 


StringBuilder sduery - new StringBuilder ( ) ; 
SURL - http://myserver/public/probamail.eml; 
sduery.Append(e"C?xml version-"1.07?2"); 
sduery . Append( "£d:propertyupdate xmlns:d-"DAV:" 
4 xmlns:cs"urn:schemas:httpmail:"2"); 
sduery.Append( "£d:set2"); 

sduery . Append( "£d:prop2" ) ; 

sduery.Append( "£c:displaynamezattachmail.eml 
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§ €/c:displayname2"); 

sduery .Append( "C£c:subject?2Level csatolt 
B allomannyalk/c:subject2"); 
sduery.Append( "£c:htmldescription2Ez a 
B. levél targyak/c:htmldescription?" ); 
sduery . Append( "£/d:prop2") ; 
sduery.Append( "£/d:set2"); 

sduery . Append( "£/d:propertyupdate2" ) ; 


A különbségek tehát a következők: az XML kérés gyökéreleme 
propertyupdate lett, majd a prop és set tagek belsejében 
megadhatjuk a létrehozandó levél tulajdonságait. Ebben a pél- 
dában a displayname-en kívül a levél tárgyát, illetve a törzsét 
adtuk meg a htmldescription jellemzőben. 

Ezzel az e-mail létrehozásához szükséges kérés megvan, küldjük 
el a szervernek: 


XMLHTTP3O oXML - new XMLHTTP3OC(); 
oXML . open ( "PROPPATCH", sURL, false, 

9 e"myserverNuser" , "password" ); 
oXML . setReguestHeader ( "Content -type: " , 
B "text/xml" gs 

oXML.send( sduery) ; 


Ugye ismerős? Egyetlen eltérés van az előző küldéshez képest: 
a PROPPATCH metódust hívtuk meg. A levél létrejött, csatoljunk 
hát hozzá egy állományt! 

Első lépésként olvassuk be a lokális fájlrendszerből: 


FileStream fs - new FileStream( 

WC: VWAgivVWvalami. doc" , FileMode. Open); 
byte[] bytes - new Byte[(fs.Length]; 
fs.Read(bytes, DO, (int) fs.Length); 


Most jön az érdekesség: a WSS a levelekhez csatolt fájlokat 
streamként tárolja, ami azt jelenti, hogy következőképpen lehet 
rá hivatkozni: 


String fURL - "http://myserver/public/ 
b probamail.eml/proba. doc" ; 


Mintha a levelünk maga is egy collection lenne! 

Vajon mi látszik mindebből a propertyk szintjén? Csupán annyi, 
hogy a urn:schemas:httpmail:hasattachment (read-only) pro- 
perty jelzi, van-e csatolt állomány a levelünkhöz. 

Itt jegyzem meg, hogy az Exchange SDK-val együtt telepíthető 
a gépünkre egy Exchange Explorer nevű alkalmazás, amellyel jól 
nyomon követhetők a WSS-ben történő változások. 
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DAV-ereatondate ——— daleTimetz  200203-07T0821:42.2287 

DAV-dsplayname sing Pubic Folders 

DAV:getcontentlength int o 

DAV-haschádren boolean 1 

DAV-hassubs bociean 1 

DaV-hrel sting htp Minyserverpute 

DAVid seg ADEAAÁKAAAABI 

DAV-rcolection boclean ú a 
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Az ablak bal oldali része (Exchange Store 
Hierarchy) a WSS hierarchiánkat mutatja, 
abból a gyökérből kiindulva, amit az 
indításkor megadunk neki. 
A jobb oldali ablakrész a részleteket 
szemlélteti. Felül a hierarchiában kijelölt 
mappához tartozó sémadefiníciókat, és a 
mappában található elemeket tekinthetjük meg. 
"3. —— Alul egy-egy elem kijelölésekor megjelennek 
annak propertyjei, névtereik szerint rendezve. 
Az Exchange Explorer használata tehát nagyon egyszerű, logi- 
kus, struktúrája világos, áttekinthető. 
Térjünk vissza azonban eredeti problémánkhoz, a csatolt fájl beszú- 
rásához. Ott tartottunk, hogy megvan a beszúrandó állomány, meg- 
van, hogy hová kell beilleszteni, jöjjön tehát, 
aminek jönnie kell: 


XMLHTTP3O fXML - new XMLHTTP3O( ) ; 
fXML . open("PUT", fURL, false, 

$  e"myserverNuser" , "password" ) 
fXIML . setReguestHeader 

4 ( "Content-type: " , "text/msword" ) ; 
fXML . send(bytes) ; 

fs.Close( ); 


Két dolgon akadhat meg a szemünk: a PUT metódus jelöli, hogy 
állományt akarunk feltölteni; a senddel pedig nem kérést kül- 
dünk el, hanem a fájlunk tartalmát reprezentáló bytes tömböt. 
Máris láthatjuk például az Exchange Explorerben, vagy az Out- 
lookban próbálkozásunk eredményét! 


Ne felejtsük azonban: az XMLHTTP még COM-os objektum, előttünk 
áll még a feladat, hogy szebb, , modernebb" megoldás után nézzünk. 


WebReguest és WebResponse 

Ezennel elérkeztünk a .NET világába. A WebReguest és a Web- 
Response már .NET-es osztályok, a System.Net névtérben talál- 
hatók. Nem kell külső DLL-ekre, COM objektumokra hivatkozni, 
a Framework kielégíti minden igényünket. Lássuk, hogyan! 

A kérés, ami a WSS-hez érkezik, hasonló lesz az előzőekhez, azonban 
a kiszoláglóhoz történő küldésének módja kissé más. Most a 
WebReguest példányunk jellemzőit állítjuk be a megfelelő értékekre: 


WebReguest reguest - lWebReguest.Create(sURL) 
reguest.Method - "SEARCH"; 
reguest.Credentials - new NetworkCredential 
W.("user", "password", "domain" ); 
reguest.ContentType - "text/xml"; 
reguest.ContentLength - sduery.Length; 


Beállítjuk tehát a metódust, a felhasználót és a tartalom típu- 
sát. Végül meg kell adnunk (nagyon fontos!) a kérés hosszát is, 
mert e nélkül a kiszolgáló nem tudja értelmezni azt. 

A kérés továbbításához létrehozunk egy StreamWritert (System.IO 
névtér), amely a Reguest Streamünkbe ír, majd beleírjuk a lekér- 
dezést, s lezárjuk: 


Streamdriter writer - new 

ks Streamlriter(reguest . GetReguestStreanm-( ) ) ; 
writer.Write( s£uery) ; 

writer.Close( ); 
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A WebReguest és a 
WebResponse már 
. NET-es osztályok, a 
System.NET névtérben 
megtalálhatóak. 


windows / 


A választ egy WebResponse objektumban kapjuk vissza: 
WebResponse response - reguest.GetResponset( ) ; 


Ennek GetResponseStream() metódusával érhető el a választ 
reprezentáló Stream, amit aztán ismét igényeinknek megfele- 
lően dolgozhatunk fel. 


A válasz feldolgozása 

Mindkét típusú keresésnél hivatkoztam arra, hogy válaszként 
streamet kapunk. Ennek feldolgozására mutatok most egy egysze- 
rű példát. Az utóbbi, .NET-es megoldásra alapozva az alkalmazás 
elve az, hogy egy XmlReaderbe kiolvassuk a választ (System.Xml 
névtér) , majd ezen megyünk végig. 


WebResponse response - reguest. 
GW GetResponse( ) ; 

Stream stream - 

Wresponse . GetResponseStrean( ) ; 
XmiTextReader xr - new 
WXmiTextReader (stream) ; 

xr . MoveToContent( ) ; 


Az xr.Read() metódus a következő XML elemre ugrik a dokumen- 
tumban, és egy bool típusú értéket ad vissza: mindaddig igaz, 
amíg el nem éri az XML dokumentum végét. Azt, hogy az XML 
tag nyitó vagy záró éppen, az IsStartElement() metódus adja 
meg: értéke igaz nyitótagekre, hamis a tag záró párjára, illetve 
a tagek belsejében szereplő értékekre. Például: 


£XKpelda2Ez a belsejeC/pelda2 


esetén: 

xr kurzor (xr.Read()) IsStartElement() 
£pelda2 True 

Ez a belseje False 

£/pelda2 False 


Lássuk tehát, hogyan írathatjuk ki a képernyőre a kiszolgáló 
XML válaszát: 


while (xr.Read()) ( 
stringBuilder s - new stringBuilder( ); 
if (xr.IsStartElement( )) ( 
s.Append(xr.Name) ; 
s.Append(" - "); 
xr.Read( ) ; 
if (!xr.IsStartElement( ) ) ( 
s.Append(xr.Value); 
4 24 at 
Console.WriteLine(s); 
Tk 97 ár 
) // while 


Ha kényelmesebben, DOM-on keresztül akarjuk feldolgozni a ka- 
pott xml választ, akkor az XmIDocument osztályt inicializálhat- 
juk az XmlTextReader példányunkból. 

A lehetőségek végeláthatatlanok: a képernyőre íratással nem 
merül ki a tudomány. Az adatokból készíthetünk DataSetet, 
építhetünk táblázatot, szűrhetjük azokat kliensoldalon (például 
különböző nézetek létrehozására) , stb. 





ZONG. 04: 


Mire jó mindez? 

Jogos a kérdés, hiszen manapság annyi alkalmazás van már a 
piacon, ami mind az Exchange Server elérését támogatja, hogy 
már csupán ezek nyomon követése is szép harci feladat: hogy ne 
menjünk messzire, ott az Outlook. Az Interneten is találhatunk 
jónéhányat, akár az MSDN-en is [4]. 


A helyzet azonban az, hogy ezek az alkalmazások már készen ke- 
rülnek elénk, és vagy egyáltalán nem, vagy csak kis mértékben 
alakíthatók a mi igényeinkhez. (Természetesen nem arra gondolok, 
hogy az Office Assistant kiskutya vagy mosolygó piros labda formá- 
Jában jelenjen-e meg...) Szükségünk lehet például arra, hogy sa- 
ját WSS mappánkhoz olyan nézeteket generáljunk, amelyek a sa- 
ját jellemzőinket is megmutatják, a saját igényeink szerint. 

Például ha az elmúlt évi nyaraláson készült képeinket a WSS-ben 
szeretnénk tárolni, akkor azokhoz nyugodtan hozzárendelhe- 


tünk egy sajatnevter:mivoltez jellemzőt, amelyben 
leírhatjuk, milyen eseményhez, a nyaralás melyik 
pillanatához kapcsolódik a kép. Vagy létrehozhatunk 
egy sajatnevter:kikvannakrajta jellemzőt. És még so- 
rolhatnám. Ha saját alkalmazást írunk, mindez lehetővé 
válik, sőt, még a dokumentumok (képek) is úgy jelennek meg, 
ahogyan mi szeretnénk. Például a képek kis méretben, mellette 
a helyszín, az időpont, az esemény, stb. Ezek alapján aztán már 
szűrhetünk is, csoportosíthatunk, a lehetőségeknek csak a kép- 
zeletünk szab határt. 





Jó móka, nem? 


Molnár Ágnes 
agnes.molnar odataware.debis.hu 
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Common Language Runtime az MSDN-en: 


[1] ms-help://MS.NETFrameworkSDK/cpguidenf/html/cpconcommonlanguageruntimeov 
[2] http://msdn.microsoft.com/library/en-us/cpguide/html/cpconthecommonlanguageruntime.asp?frame-true 


A WebDAV metódusok az MSDN-en: 


181 http://msdn.microsoft.com/library/default.asp?url-/library/en-us/wss/wss/ webdav methods.asp 


Exchange2000 Serverhez kapcsolódó alkalmazások: 


[4]http://msdn.microsoft.com/downloads/default.asp? URL-/downloads/sample.asp?url-/msdn-files/027/001/833/ 


S msdncompositedoc.xml 


[5] Exchange SDK Development Tools March 2002 


http://msdn.microsoft.com/downloads/default.asp? URL-/downloads/sample.asp?url-/msdn-files/027/001/833/ 


S msdncompositedoc.xml 
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Legyen Ön is BUG Hunter! 

A hivatalos egyenruhát képező speciális vadásztrikó 
kiérdemléséhez mindössze annyit kell tennie, hogy az 
Ön által felfedezett BUG-okat levadássza! Hogy hol 
találhatja Őket? Ismeri a természetüket, természete- 
sen bárhol a magazinban. A vadászat eredményéről 
értesítsen minket, hogy mielőbb elküldhessük Önnek a 
hivatalos egyenruhát. 

Szerencsés vadászatot! 


Szabályzat: 

1) Minden hiba ELSŐ felfedezőjének jár póló. 

2) Hibajelentés a weben: 

3) A vadászat minden számnál a következő szám megjelenéséig tart. 


EDES. BZ. 


EL 


u33SÁS a5beJgojs gam sa usanuag 
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Routolás RRAS nélkül 

K: RRAS nélkül szeretnék routerként használni Windows 
2000-et. A Windows NT 4.0 TCP/IP beállításai közt, az egyik 
ablakban volt egy olyan lehetőség, hogy , Enable IP 
Forwarding". Hova lett ez a Windows 2000-ben? 


V: Sem a Windows 2000-ben, sem az XP-ben nincs felület a routing 
bekapcsolására. A registry módosításával viszont be lehet kapcsolni. 
Registry editorral a következő kulcs alá, REG DWORD típussal 
kell felvenni az IPEnableRouter értéket. 


HKEY. LOCAL MACHINENSYSTEMNCurrentControlSetV 
ServicestTcpipNParameters 
IPEnableRouter-1 


Ezzel az összes hálózati csatolóhoz bekapcsoljuk a routolást. 
Ha 0-ra állítjuk az értéket, vagy letöröljük a létrehozott értéket, 
megszüntethetjük a routolást. 

(Forrás: MS Technet 0230082) 


Terminálkiszolgáló leállítása 

K: Ha a Windows 2000 terminál szervert szabályosan indítom 
újra, a felhasználók nem értesülnek róla, hogy alattuk a szer- 
ver újraindul, s egyszer csak eltűnik. Van arra egyszerű mód- 
szer, hogy a felhasználók automatikusan értesüljenek arról, 
hogy a szerver újraindul? 


V: Ha a tsshutdn parancsot használjuk a terminál szerver leál- 
lításához, az elintézi a felhasználók értesítését is, sőt ki is lép- 
teti a felhasználókat. Ez a parancs az operációs rendszer része. 
Vigyázat! Az egész gép újraindul, nem csak a Terminal Services! 
A parancs szintaktikája a következő: 


hut down a server ín a controlled nanner, 





SSHUTDN [unit SERVER: servernane1 £/REBOOT1 (/POVERDOUNI 
CDELAY: logoffdelayi /01 


vaát.tine 
t 
SERVER: servernane 
ZREROOT Kei 
ZPOMERDOUN The 
DELAY: logoffdelay ayzát 
A Bísplay infornatáon about actions beiny perforned. 





1 
:NDocunents and Settínyzvádninástratorztsshutdn /T 





"B wait time: megadhatjuk, hogy a parancs kiadása után meny- 
nyi ideig várjon arra a leállítás, hogy kilépjenek a felhasz- 
nálók. Alapértelmezésben ez 1 perc. Amikor letelt az idő, el- 
kezdi kiléptetni a bennmaradt felhasználókat. Természete- 
sen rögtön a parancs kiadása után a felhasználók értesülnek 
arról, hogy a szerver x idő múlva leáll. 

8 /server cserver names : ha távoli szervert szeretnénk leállí- 
tani, ezt a kapcsolót használjuk. Ha nem adunk meg távoli 
gépet, akkor értelemszerűen a helyi szerver lesz az áldozat. 

"h /reboot - szerver leállítás után rögtön újraindítás következik — 
ennek a kapcsolónak nem sok értelme, hisz az újraindítás az alap- 
értelmezett művelet, mégha nem is használjuk ezt a kapcsolót. 

"2 /powerdown - ezzel a szervert leállítás után kikapcsolhatjuk. 

"B /delay ctimez - miután kiléptette az összes felhasználót, meny- 
nyi időt várjon a folyamat a leállítás előtt. Ez alapból fél perc. 

"§ /V - bőbeszédűbb infót kapunk vissza arról, mi is történik. 


vwvóoórking vith 
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Dupla KV 


Ha a parancsot egyszerűen, minden kapcsoló nélkül kiadjuk, ak- 
kor a következő történik: a folyamat a felhasználók értesítése 
után 1 perccel kilépteti a még bennlevőket, majd vár még egy 
fél percet, mielőtt újraindítja a gépet. 


DFS replikáció finomhangolása 
K: Hol tudom állítani, hogy a DFS replikáció mikor fusson le, 
illetve hogyan lehetne időzíteni? 


V: A DFS a File Replication Service (FRS) segítségével replikál. 
Az FRS működését csak a registry módosításával lehet szabá- 
lyozni. A registryben itt találhatók a DFS beállításai: 


HKEY LOCAL MACHINENSystemiCurrentControlSetN 
ServicesMNtFrsXAParameters 


A beállításokról bővebben lehet olvasni a Microsoft Technet 
0221111 KB cikkben. 


(Forrás: Windows 2000 levelezési lista) 


Exchange 2000 Mailbox jogok 
K: Hogyan lehet megcsinálni, hogy a rendszergazda lássa az 
Exchange 2000 M: meghajtóján az összes felhasználó mappáját? 


V: Legalább három úton lehet eljutni a megoldásig. 

1. A legelegánsabb, ha a rendszergazda , Receive As" jogot 
ad magának az Exchange Organization szintjén. Ezt úgy te- 
hetjük meg, hogy a következő registry túrással megjelenít- 
jük a Exchange System Manager Security fülét: 


HKEY. CURRENT. USERNSOFTUAREMicrosoftNExchangeN 
ExAdminN 
ShowSecurityPage-l 


Majd a System Managerből a legmagasabb szinten ellátjuk 
magunkat , Receive As" joggal. 

Ugyanezt registrymódosítás nélkül, ADSIEdittel is elvégez- 
hetjük. A ,Receive As" jogot a következő objektum tulaj- 
donságainak Security fülén állíthatjuk be: 


Configuration Conatiner 
CN-Configuration 
CN-Services 
CN-Microsoft Exchange 
CN-XOrganization Name? 


Vigyázat!! Ha a felhasználó tagja a Domain Admins, vagy az 
Enterprise Admins csoportnak, ez a jog gyárilag ,deny", 
azaz tiltott. Ilyenkor elegendő a tiltás megszüntetése, és 
máris az összes levelesládába belelátunk. Ezért két évig ter- 
jedő szigorított fegyház jár (lásd 18. oldal)! 

2. Nem elegáns, de működő módszer, ha betesszük magunkat 
az Exchange Domain Servers csoportba. Kicsit veszélyes is, 
ezért öt év jár! 
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3. A harmadik módszer, hogy a levelesládák szintjén játszunk 
a ,Receive As" joggal, illetve , Full Mailbox" jogot adunk 
magunknak. Felhasználói szinten a ,Receive As" jogot az 
Active Directory Users and Computersben, a felhasználó tulaj- 
donságainak Security lapján találjuk. A , Full Mailbox" jogot 
pedig az Exchange Advanced lapon, a Mailbox Rights alatt. Ez 
csak szabálysértés, és pénzbüntetést von maga után. 


(Forrás: Exchange 2000 levelezési lista) 


Group Policy megnyitása egy adott DC-ről 

K: A Domain Administrators csoport tagjaként a Group Policyt 
egy olyan tartományvezérlőn próbálom szerkeszteni, amelyik- 
re hisecdc template lett rá húzva. Nem ez a tartományvezér- 
lő a PDC emulátor. A következő hibaüzenetet kapom a házi- 
rend megnyitásakor: 

Failed to open the Group Policy Object. You may not have 
the approriate rights. The specified domain either does not 
existor could not be contacted." 

Az igaz, hogy a PDC emulátor épp nem megy. Hogyan tudnám 
mégis megnyitni a GPO-t? 


V: Itt a ,hiba" oka! ,,...the specified domain either does not 
exist or could not be contacted..." 

A GPO Editor alapértelmezésben először a PDC Emulátorhoz kap- 
csolódik. Ha ez nem fut, akkor feldobja a , Select another DC" 
ablakot. Tegyél így, select another! 

A GPO Editornak meg is lehet mondani, hogy hova csatlakozzon 
legközelebb. Három lehetőség van: 


Options for domain controller selection KER 
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"When Group Policy is selecting a domain controller, it will use the option 
chosen below. There is a policy that may ovenide this preference. This will 
take effect the next time this snapin is started. 


€ The one with lhe Operationz Master teken for the POC emulator 


6 [fheone used by the Aciív 
C Use any available domain controller 


Lee T tema] 


a DC Options 





1. A PDC emulátorhoz csatlakozik - ez az alapbeállítás. 

2. Ahhoz a tartományvezérlőhöz kapcsolódik, amelyikhez az 
Active Directory Users and Computers MMC snap-in is. 

3. Bármelyik elérhető tartományvezérlőhöz csatlakozik. 

Mindezt úgy lehet átállítani, hogy megnyitunk egy Policyt, majd 

a Policy objektumon állva a View menüben megkeressük a DC 

Options menüpontot. 


II. Action Wew  Eavartes [6 5] 
iga Í Fa Choose Columns... 













Tree [Fay 
(TD Consok Large Icons 
B-EMLEM Smallicons 
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EH: 9 Detal 
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fi 


(-CI Windows Settings 
H-T Administrative Templates 





5 DC választás a GPO Editorban 


(Forrás: Security levelezési lista) 


A Windows 2000 roaming profile könyvtárak jogai 

K: Windows 2000 környezetben ha egy új felhasználónak Roamain 
Profilet állítok be, később még Admin jogokkal sem tudom a 
Profile könyvtárat és tartalmát törölni. Rendszergazdaként 
hozzá kellene férnem a felhasználók Roaming Profiljaihoz. 
Van erre megoldás? 
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V: Háromféle megoldás is létezik: 

1. Az egyik, ha a felhasználó profilkönyvtárán a 
Take Ownership" joggal élünk, és - az 
Administrators csoport tagjaként - magunkévá 
tesszük a felhasználó teljes Profile könyvtárát és tar- 
talmát, majd megfelelő jogokat adunk magunknak. 

2. Jobb módszer, ha a felhasználó létrehozásakor (még mielőtt 
belépne) létrehozzuk a Roaming Profile-hoz azt a könyvtárat, 
amit beállítottunk. Így nemcsak a felhasználónak, hanem a 
rendszergazdá(k)nak is jogot adhatunk a könyvtárhoz. 

3. Legjobb módszer, ha a Default Domain Policyben beállítjuk, 









hogy a profile könyvtárak jogaihoz adja hozzá az 
Administrators csoportot is. 
Defadt Doman Polcy [iga het. 7 ( ETEETEZZTTTEZTETE ETTE eres üt 2121 
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(3-CI Software Settings Poley ] Esotöin] 


TÁ Add the Administrators secutily group to roaming uset proldez 





(I Group Policy 


3-CI Network. 


5-CI Software Settings 
53-CI Windows Settings 


5 Profile könyvtárak jogainak állítása Group Policy segítségével 


Ez a beállítás csak számítógépekre értelmezett. Tehát nem elég 
a profilokat tartalmazó szerveren beállítani, hanem ki kell ter- 
jeszteni az ügyfélszámítógépekre is, mivel az első belépéskor a 
jogok beállítását az ügyféloldal szabályozza. 


Könyvtár/fájlméretek meghatározása egy könyvtárstruktúrában 
K: Van tudomása bárkinek olyan programról, amivel egy 
könyvtárstruktúrában rekurzívan ki lehet gyűjtetni a legna- 
gyobb méretű fájlokat vagy könyvtárakat? Nálunk napról 
napra csak fogy a hely, és rejtélyes könyvtárakat, bennük ha- 
talmas telepítőkészleteket találok. Ezeket szeretném vala- 
hogy automatikusan megtalálni. 


V: Használjuk a Windows 2000 Resource Kit diruse segédprogi- 
ját, az pont erre való. 

Vigyázzunk, hogy a vizsgált területen mindenhova legyen jo- 
gunk, mert csak azokat a könyvtárakat tudjuk elemezni, amelyek 
tartalmát el tudjuk olvasni. A profilkönyvtárak tartalmát például 
nem. Kibúvó: legjobb, ha Backup Operators csoport tagjaként 
futtatod a programot. 

(Forrás: Windows 2000 levelezési lista) 


Jelszóváltoztatás webes felületről 
K: Webes felületen hogyan tudom a felhasználónak biztosíta- 
ni, hogy megváltoztassa a jelszavát? 


V: Ha NT4 domainben, vagy Active Directoryban lévő felhasználó- 
ról van szó, akkor ADSI-val lekérhetjük a felhasználót egy IADSUser 
objektumba, majd annak meghívhatjuk a SetPassword metódusát. 
Példa: 


Dim usr As IADsUser 
Set usr - GetObject( "WinNT: //Microsoft/JSmith, user") 


usr .SetPassword "topsecret98" 


(Forrás: fejlesztői levelezési lista) 
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RAM vizsgálat programból 
K: Csereprocesszor nélkül meg lehet-e valahogy vizs- 
gálni a processzort valamilyen diagnosztikai prog- 
rammal? (Mert amennyire én tudom, a RAM-ot is csak 
cserélgetéssel lehet.) A RAM hibát ki lehet zárni a három RAM 
modul cserélgetésével. Úgy tűnik, nem ezzel van a gond... 


V: Már miért ne lehetne a RAM-ot programmal tesztelni? Igaz, ki- 
sebb hatékonysággal és alapossággal, mint egy speciális teszter- 
rel, de vannak nagyon jó programok is erre. Ami nálunk nagyon 
bevált, a ramexam nevű program, az [1] címről beszerezhető. 
A processzor vizsgálatára is vannak programok, mondjuk vala- 
melyik Checkit. Azért ez nem RAM, ahol minták beírásával, illet- 
ve annak korrekt visszaolvasásával lehet a hibát meghatározni. 
(Forrás: Windows 2000 levelezési lista) 


Kredencek ütközése 

K: Most installáltam egy Active Directoryt a hálózaton az 
egyik gépre. Egy Windows NT-ről be akarok lépni erre a gép- 
re, és azt írja ki, hogy: ,, The credentials supplied conflict with 
an existing set of credentials." 


V: Az a baj, hogy hozzá vagy már kapcsolódva. 

Parancssorból add ki a net use " /del parancsot, és meglátod, 
menni fog! Vagy kapcsolódj FODN néven a másik szerverhez. Az 
FODN (vagy IP-cím) és a NetBIOS névvel történő kapcsolódás két 
külön dolog, ezért egymással párhuzamosan, más felhasználói 
névvel is lehet így csatlakozni. 

Tehát kétféle módon is kapcsolódhatsz egy időben: 


net use Niserverl /user:domainozsi 
és 
net use Niserverl.domain.net /user:domainlPisti 


vagy 
net use W292.258.0.21 /user:domainMPisti 


(Forrás: Windows 2000 levelezési lista) 


Kiterjesztés nélküli fájlok megnyitása 

K: Az egyik programunk kiterjesztés nélküli fájlokat generál. 
Már nagyon unom, hogy mindig rákérdez ezeknél a fájloknál 
az Explorer, hogy mivel is akarom megnézni, és nem engedi, 
hogy rendeljek hozzá programot. Van valami megoldás erre? 


V: Ilyen fájlok esetén a registry módosításával lehet megadni az 
alapértelmezett programot. Egy .reg kiterjesztésű fájlba írjuk be 
a következőket: 


Windows Registry Editor Version 5.00 
[HKEY. CLASSES ROOTN.] 

ez" SPEC" 

IHKEY. CLASSES ROOTNSPECI 

[HKEY. CLASSES ROOTNSPECXshel1] 

IHKEY. CLASSES  ROOTNSPECYshelltopen] 

[HKEY. CLASSES ROOTNSPECYshellvopenvcommand] 
ez"c:VWwinntWnotepad.exe NZIRN"" 


Az első és az utolsó sor az operációs rendszertől függően más le- 
het. Természetesen a notepad.exe csak egy példa. Az utolsó sor- 
lyikkel a kiterjesztés nélküli fájlokat meg akarjuk majd nyitni. 

A .reg fájlt könnyedén hozzá tudjuk adni a registryhez (jobb 


vorking with 


windows / 


klatty — Merge, vagy egyszerűen dupla klikk a fájlon). 
Ha nem csinálunk .reg fájlt, egyszerűen registry editorral is lét- 
rehozhatjuk ezeket a kulcsokat és értékeket. 


XP-be épített ZIP tömörítő kiiktatása 

K: Nincs szükségem a Windows XP-be beépített tömörítőre, 
szeretnék megszabadulni tőle. Lehetséges ez? 

V: Igen. A beépített tömörítést a system32-ben található 
zipfldr.dil végzi. Ki lehet iktatni, a következő paranccsal: 


regsvr32 /u Zsystemrootzisystem3gNzipfldr.dll 


A gép újraindítása után már nem fog működni a beépített 
tömörítő. Ha később mégis használni kellene, akkor a /u nélkül 
kiadva ugyanezt a parancsot, újra használhatóvá válik a funkció. 


XP Windows Messenger kikapcsolása 

K: Szeretnék megszabadulni a Windows Messengertől. Nem 
használják a felhasználók és nem is szeretném ha használni 
tudnák. Ne is jelenjen meg induláskor, sem később. 

V: Group Policy segítségével le lehet tiltani a Messengert. A Local 
Policy-ban ezt két helyen is meg lehet találni, egyszer a felhasz- 
nálók, egyszer pedig a gép beállításai közt. Mind a két helyen 
a az Administrative TemplatestWindows ComponentsWindows 
Messenger útvonalon van két beállítás. 


Ta e eza Ta s 1 


Do not allow Windows Messenger to be run 
Do not automatically start Windows Messenger initially 






Not configured 
Not configured 


5 A Messenger letiltása 


Ha mind a kettőt , Enabled" állapotra hozzuk, akkor nem tudják majd 
használni a felhasználók a Messengert és a gép indulásakor sem fog 
betöltődni. Ha a gép és a felhasználók beállításai közt is állítjuk a 
konfigurációt, akkor a gépre érvényes házirend fog érvényre jutni. 


XP és a NetBEUI 

K: Jól látom, hogy nem látom a NetBEUI-t a Windows XP 

Professional-ben? Ha lehet ilyet használni XP-ben, akkor 

hogyan kell beállítani? 

V: A Microsoft KB 0301041 cikke adja meg a választ. Lehet, de 

manuálisan" kell feltenni, mert a NetBEUI ezentúl nem tá- 

mogatott protokoll. 

A cikk tartalma nagyjából a következő: Összesen két fájl kell a 

NetBEUI működéséhez: a netnbf.inf és a nbf.sys. Ezek a fájlok 

az XP telepítő CD-n a ValueaddMSFTWetMWetBEUI könyvtárban 

találhatóak. A telepítés menete a következő: 

1. Az nbf.sys-t be kell másolni a 
MJOSYSTEMROOT9o System32 Vrivers könyvtárba. 

2. Az Netnbf.sys-t be kell másolni a 99SYSTEMROOT9Unf 
könyvtárba. 

3. A Control Panelben vegyük elő a Network Connectionst. 

4. A hálózati kapcsolatok közül válasszuk azt, amelyikhez 
szeretnénk NetBEUI-t rendelni, majd jobb kattintás után 
válasszuk a Tulajdonságokat. 

5. General fülön kattintsunk az Install gombra, majd Protocol 
- Add, ezután válasszuk a NetBEUI-t, végül az OK gombot. 

6. Utolsó lépésként indítsuk újra a gépet. 


A cikkben szereplő URL-ek: 


[1] http://www.gualitas.com/product/ramexam/whatisre.htm 
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Farsite 





Úgy tíz évvel ezelőtt egy Deltában láttam, amint japán kutatók bemutatták, 

hogyan tudnak szemétből gyémántot előállítani, mondhatnám varázsolni. Önkéntelenül 
ez jutott eszembe, amikor először hallottam a Farsite-ról, mert ezzel temérdek 
ócskavasból (azaz idejétmúlt, de még nem teljesen használhatatlan számítógépből) 
gigászi tárhelyet, amolyan internetes bőségszarut építhetünk. 


Mi is tehát a Farsite? Egy szimbiotikus, kiszolgáló nélküli, 
elosztott állományrendszer. Ez tuti jól hangzik, de mit jelente- 
nek e felemelő, marketingízű jelzők egy állományrendszer ese- 
tében? Vegyük ezeket sorra! 

A biológiából kölcsönzött szimbiózis szó kölcsönösen hasznos 
együttélést jelent. Az ebből alkotott jelző rendkívül találóan ír- 
ja le a Farsite közösség számítógépeinek (felhasználóinak) hely- 
zetét. Mindenki hasznot húz a tagságából, hiszen élvezi a 
Farsite ,növelt értékű" szolgáltatásait. A kölcsönösség abban 
nyilvánul meg, hogy , cserébe" mindenki ad tárhelyet a többiek- 
hek (nem kötelező, de elég valószínűtlen, hogy ne ezt tenné az, 
akinek akad némi fölösleges bájt a merevlemezén) 

A kiszolgálóval működő elosztott állományrendszer nem ismeretlen 
fogalom sem a Windows, sem a Unix világában. Sajnos azoknál 
egyetlen, központi gép tartja számon, hogy a globális névtér egyes 
részei hol találhatók a valóságban. Ha ez a gép elesik, oda minden. 
Nem úgy a Farsite esetében, ahol maga az állományokat nyilván- 
tartó címtár is elosztott. Ennek eredményeképpen nem számít, ha 
néhány gép tönkremegy, netán kikapcsolják azokat, mert a redun- 
dáns felépítés következtében továbbra is összeállítható lesz a kér- 
déses állomány a még működő gépekről. Magától értetődően előáll- 
hat olyan olyan állapot, amikor egyes fájlok nem elérhetők, de ez 
már egy adott rendszer tervezésének kérdése. A központi kiszolgá- 
ló mellőzésének van még egy nagy előnye, amire a vezető beosztá- 
sú informatikusoknak biztosan felcsillan a szeme: nem kell hozzá 
rendszergazda, és ezzel tovább faraghatók a bérköltségek. A közös- 
ség tagjai maguk szabják meg, hogy erőforrásaikat ki használhatja. 
A házirendet jelenleg úgy képzelik, hogy a közösbe bedobottal ará- 
nyos nagyságú tárhely használható. Tulajdonképpen ez a legfonto- 
sabb tulajdonság, és nemcsak azért, mert a költségcsökkentés a 
döntéshozók vesszőparipája, hanem mert ezt mindez idáig csak a 
Farsite tudta megvalósítani. 

A címtár mellett magukat az állományokat is elosztott módon tá- 
rolják. A recept szerint mindent apró ,kockákra" vágnak, majd 
ugyanazt a darabot több helyen is elmentik. Mindezt leginkább egy 
hálózati RAID rendszerhez lehetne hasonlítani. Nem vész el némi 
tárhely a redundancia miatt? Talált, süllyed, de csak félig, mert ezt 
az a technika hivatott kompenzálni, amely az egyazon gépen lévő, 
azonos fájlokat összeolvasztja - részben a Windows 2000-ben már 
megtalálható Single Instance Storage módszer segítségével. 

Az [/0 teljesítmény drasztikus esése miatt sem kell aggódni, mert 
az adott időn belül használt fájlok egy változó méretű, lokális gyor- 
sítótárban is megtalálhatók. 

Nem is tudom miért, de úgy érzem, hogy itt egy termékgyanús 
rendszerrel állunk szemben. Ebben az esetben viszont piac is kell. 
Kinek kell majd egy ilyen állományrendszer, és miért? 

A Farsite projekt célközönségét olyan intézmények alkotják, ahol 
mintegy 10 gépen 10" számú állományban 10" bájt adatot tárol- 
nak. Százezer bizony nagy szám, és itt sokan talán azt gondolják, 
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hogy ezt már nem is érdemes tovább olvasni. De igen, érdemes. A 
Farsite rendszerek kialakítását ugyanis nem feltétlenül egy vállalat- 
nak, egyetemnek stb. kell kialakítani. Ezt a hálátlan, de valószínű- 
leg jól jövedelmező feladatot direkt erre specializálódott szerveze- 
tek, esetleg a jelenlegi Internetszolgáltatók fogják felvállalni. Ők 
lesznek a tárközvetítők. Vállalatok, egyetemek és más intézmények, 
sőt, akár magánszemélyek is ezeken a közvetítőkön keresztül fér- 
nek hozzá némi díjazás ellenében a bőségszaruhoz, és ugyanígy 
ajánlhatják fel saját táruk egy részét a Farsite közösség javára, szin- 
tén némi díjazás ellenében. Így vagy úgy, előbb-utóbb mindenki 
számára elérhető lesz a szolgáltatás. 

Akár egyéni felhasználót, akár egy intézményt tekintünk, felmerül 
a biztonság kérdése. Beszállok ebbe a buliba, és vadidegen gépe- 
ken tároljam a szerelmes leveleimet? Ez így nem kóser. Valóban. 
De egy gépen legfeljebb néhány morzsa, apró ,kocka" található 
ugyanabból az állományból, így több felhasználó összefogása kel- 
lene ahhoz, hogy a teljes puzzle-t kirakják. És mi van, ha össze- 
fognak, hogy legbelsőbb titkaim felfedjék? Csak semmi pánik! Ha 
még nem mondtam volna, a morzsákat titkosítják, a hozzáférést 
pedig digitális aláírások révén ellenőrzik, így aztán összefogás ide 
vagy oda, a lecke fel van adva a cracker-társadalomnak. 

Legyünk paranoiásak, és tegyük fel, hogy a gonosz crackerek át- 
verekszik magukat a biztonsági vonalakon, és néhány gépen sike- 
rül megváltoztatniuk a szerelmeslevelet felmondólevéllé. Ekkor az 
a furcsa helyzet áll elő, hogy a levelem néhány gépen szerelmes 
lesz, néhányon viszont felmondó. Mi az igazság? Ez az ún. bizán- 
ci probléma: a csatára készülő seregeket több tábornok és a főpa- 
rancsnok vezeti, akik futárok segítségével üzenhetnek egymásnak. 
Vagy mindannyian egyszerre támadnak, vagy egyikük sem. A dön- 
tést a főparancsnok hozza meg. A bibi mindössze annyi, hogy a 
tábornokok, de maga a főparancsnok is küldhet megtévesztő üze- 
neteket, vagyis míg egyes tábornokokat támadásra szólíthatnak 
fel, másokat épp az ellenkezőjére. A probléma megoldására több- 
féle algoritmus is létezik, és természetesen a Farsite fejlesztői is 
alkalmaznak egy ilyet a vázolt eset feloldására. 

Fontosnak tartom még azt is megemlíteni, hogy ebből a nagy 
masszából mit látok én, a felhasználó. Látok egy globális névteret, 
amiben az állományokat azok tényleges, fizikai helyétől függetle- 
nül érhetem el. Ennyit, és nem többet. Olyan ez, mintha egyetlen 
kiszolgáló állna velem szemben. A jelenlegi változatban ezt a ha- 
tást még az is erősíti, hogy a legfelső szintet egy betű jelöli: egy 
virtuális állománykiszolgáló virtuális meghajtójáé. 
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Windows: SAK? MATT! 

Nemrégiben egy kicsiny cég ügyvezetőjével beszélgettem, aki a maga szemszögéből a következőképpen látta a 
Linux kontra Windows harcot: van Windowsuk is, Linuxuk is, de a Linux - szerinte - nagyságrendekkel kevesebb 
törődést igényel (igaz, szinte semmit sem tud, mert mindent kivettek belőle, akik telepítették) . A Server Appliance 
Kit megjelenéséig nehéz volt erre okosat mondani, ma már van válasza a Microsoftnak erre a problémára. 


Research: 

Elérkeztünk a világgép sorozat harmadik részét képező második komponenshez, az elosztott, online alkal- 
mazásokhoz. A , táptalaj" a Pastry, amely a résztvevő gépek (peer-to-peer) társalkalmazásai számára elosz- 
tott, méretezhető, önszervező és hibatűrő réteget biztosít, továbbá hatékonyan valósítja meg a Pastry-gé- 
pek közötti útválasztást, a terheléselosztást és az objektumok helyének meghatározását. 


Exchange: 

Hasonlóan a Windows 2000 Csoportos házirendekhez, házirendek segítségével az Exchange egyes beállítá- 
sait is központilag lehet elvégezni. Mint minden házirend, ez is azért hasznos, mert így egy helyről lehet 
beállítani olyan dolgokat, amelyek tágabb körben érvényesek. 


Biztonság: IPSec a gyakorlatban 

E havi számunkban bemutattuk, mihez vezethet, ha az IPSec-ben, mint csomagszűrőben megbízunk. De va- 
jon nyugodtak lehetünk-e akkor, ha az IPSec-et arra használjuk, amire eredetileg kitalálták? Hogyan műkö- 
dik az IPSec? Minderre megkapjuk a választ a következő számban. 


W2000: DNS mégegyszer 
Nem is olyan régen bemutattuk a Windows 2000 dinamikus DNS szolgáltatását. Most kicsit visszanyúlunk az 
alapokhoz: hogyan viselkedik a hagyományos DNS a Windowsban? 


Exchange Web Storage System 

Az előzőekben láthattuk, hogyan tudunk információt kinyerni a WSS-ből különféle technológiákkal, illetve 
hogyan tudunk fájlokat csatolni a WSS-beli elemekhez. Mindezek mellett csak említést tettünk arról, hogy 
van lehetőségünk saját jellemzők felvételére, kezelésére. Most ezt a kérdéskört járjuk körbe. 


XMLGessünk: 
Az előző két részben áttekintettük az XML Schema alapvető elemeit, így a következő részben már megfele- 
lő elméleti alapokkal felvértezve nekiláthatunk a séma gyakorlati felhasználásának COM és .NET alapokon is. 


:NET Akadémia 

A string alaptípus lett a .NET-ben, és elég sok mindent tud. Mit érdemes róla tudni, hogyan használjuk? Mi- 
lyen tömböket és kollekciókat definiálhatunk a .NET-ben? Hogyan működik az átjárás a stringek és bájttöm- 
bök között? Ezekre a kérdésekre keressük a választ a következő részben. 


Szimpla KV 
Hogyan kell felkészíteni az Active Directoryt az XP-specifikus házirendbeállítások befogadására? 


a) A Windows 2000-es tartományvezérlőről Terminal Servicessel egy XP-re csatlakozunk, és ettől a 
háttében megtörténik a csoda: a csoportos házirend kiegészül az XP újdonságaival. 


b) A Windows XP-ről beterminálunk a tartományvezérlőre, és így megnyitjuk a csoportos házirendet. 
Ettől megtörténik a csoda... 


c) A Windows XP-n, helyben indítjuk el a házirendszerkesztőt, majd ennek segítségével csatlakozunk 
az Active Directoryra, azon belül is a megfelelő szervezeti egységre, végül a házirendre, és ettől a 
háttérben megtörténik a csoda... 
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Előfizetési szelvény 


Címzett: NetAcademia Kft. 
Faxszám: (1) dh1-7145 


Tisztelt Olvasónk! 

Lapunk hírlapárusi forgalomba nem kerül, ezért ha kíváncsi megkezdett sorozataink folytatására, kérjük töltse ki és juttassa el hozzánk 
az alábbi megrendelőlapot. Előfizetőink kedvezményesen vehetnek részt konferenciáinkon, tanfolyamainkon illetve egyéb ren- 
dezvényeinken. új 

Kérjük töltse ki ezt az előfizetési szelvényt és faxolja el az (1) 261-7145-ös faxszámra. 





AKCIÓ! 


A 2002. április 1-től indult új előfizetési 
akciónkban minden új előfizetőnk aki 

2002. július 30-ig egy évre előfizet a tech.net 
magazinra, ajándékul megkapja tőlünk a 2002. 
Januári, februári és márciusi számokat. 
Fizessen elő egy évre most, hogy küldhessük 
Önnek az ajándék magazinokat! 


Az akció határideje: 2002. július 30. 








Előfizetem a tech.net magazint: ... példányban egy évre (14.784 Ft) 
. példányban fél évre (7.392 Ft) 
. .pld.-ban.NET akcióval (12--3 szám) (14.784 Ft) 


Az előfizetés kezdete:...... Főesssi Jirméstes 
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Amennyiben a számlázási cím nem egyezik meg a szállítási címmel, kérjük az alábbi részt is töltse ki! 
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